streamwise periodicity

[Yvan Fournier]

Hello,

Here is another, more complex example, with a target velocity.

In this case, we measure the flow rate so as to compare it to the target, and adjust the source term accordingy.

This example also handles restarts using this, and used various notebook variables for parametric data. I'll let you adapt it to your needs, but this should be more complete than the previous, "minimalist" example.

Best regards,

Yvan

[ximeng]

Hi, Yvan,

Thanks! Sorry for the late reply. I've been exploring a method involving controller to dynamically adjust the momentum source term based on the difference between target mass flow and current mass flow at inlet. This approach seems quite similar to the one you provided. I will compare these two codes.

Additionally, I have encountered another issue regarding adding the thermal conditions in these streamwise periodic cases. In my case, the air temperature remains constant at 292K, while the ground temperature is 332K. I've applied the Boussinesq approximation to account for buoyancy effects. However, when using periodic boundary conditions, I've noticed a gradual increase in temperature above the canyon due to heat accumulation. I've come across papers suggesting the use of a "sink term" to mitigate this issue, but I lack detailed information, as shown in the attached picture (https://doi.org/10.1016/j.buildenv.2022.109971).

I wonder if there is any available code in code_saturne for implementing a heat sink term or any thermal source term code related to addressing this heat accumulation issue. Any information or guidance on this matter would be greatly appreciated. Thank you for your time in advance.

Best regards,
Ximeng

[Yvan Fournier]

Hello,

The cs_user_source_terms can handle both source and sink terms, so you can use it for this.

The most difficult part here is probably computing/measuring how much heat is accumulating, so as to know how which value to assign to the source term.

A relatively simple solution might be to compute the total enthalpy in the domain at each time step, compare the values between 2 successive time steps, and define a feedback sink or source term (probably with some relaxation) to try to compensate.

Best regards,

Yvan

[ximeng]

Hi Yvan,

Thanks for your suggestions about the thermal sink term. I will work on implementing this code into my case.

I am reaching out to seek help with an issue related to the cs_user_source_terms.c you provided. I just revised the selected surface to "INLET" part and added the necessary parameters in notebook. However, I am encountering unexpected output velocities and very large momentum source term. The target velocity is 1.35 m/s, but the output velocity exceeds 80 m/s. As I am not good at coding, I am unsure where the problem lies. Could you please take a look and offer some suggestions? Very appreciate!

Attached are the cs_user_source_terms.c, setup.xml files, and output run_solver.log.

Best regards,
Ximeng

[ximeng]

Hi Yvan,

Sorry for the bothering again. For the heat sink term:

I wonder if there an example of user functions to add heat sink term? I wrote a draft code (as attached) based on the discussed object but it doesn't work and no error report. There might be some errors since I am not familiar with writing code_saturne's code. Could you please also have a look if possible? I use code_saturen V7.0.

Best regards,
Ximeng

[Yvan Fournier]

Hello,

Regarding the first question, it seems that the code (based on an example) measures the mean mass flow based on the x direction, and averaging it over all interior faces.

Depending on your geometry, this might not match with the flow rate you are seeking (for example since you have a varying width, or if the mass flow rate is not aligned with x). If you have a single output, maybe computing the average flow rate based at that of the outlet might be simpler. Otherwise choosing a section at which to measure it might be best.
From the screen capture of you geometry, I cannot tell for sure in which direction the fluid flows.

For the last question, you say you have no error report. Does the code crash or do nothing ? If it crashes, running it with a debug build may help get additional error messages (and under a debugger is even better). For sink terms, (i.e. when the sign is negative), I think you can add those in the implicit part for better stability, but am not too familiar with the that, which might require an extra multiplication or division by volume or some other quantity, so you would need to check examples). In any case, if it crashes, you should get some amount of information. I did not see any obvious error in your code, but some errors are easier to spot when running under a debugger than simply reading the code. I also see you use a cell_centroid value in the mesh (different from mesh_quantities->cell_center ?), so I assume this is a modified version of the code.
If you do work on a modified version, you (or the person who did the modification) should definitely at least test on a debug build, and do some proactive testing using tools such as Valgrind. In that case, at least the tools should provide info on the
errors in case of a crash).

Best regards,

Yvan

[ximeng]

Hi Yvan,

Thanks!

Regarding the heat sink term code, I've provided the revised file. Despite multiple revisions, there remains one unresolved error. This error is specifically related to the following line:
const cs_real_3_t centroid = domain->mesh_quantities->cell_cen. The compile error report is also attached. It is used to obtain the coordinates of the cell center. Could you please have a see when you are available. Very appreciate!

For the cs_user_source_term.c, I'm certain that I've implemented the average flow rate, similar to how I've done in another source term code. The issue must lie elsewhere. I'll continue investigating and working on this.

Best regards,
Ximeng

[Yvan Fournier]

Hello,

You need to replace:

Code: Select all

const cs_real_3_t centroid = domain->mesh_quantities->cell_cen[i];

With:

Code: Select all

const cs_real_t *centroid = &(domain->mesh_quantities->cell_cen[i*3]);

Or the equivalent:

Code: Select all

const cs_real_t *centroid = domain->mesh_quantities->cell_cen +(i*3);

This is due to the array being declared as a "flat" 1D array, whereas it is more comfortable/readable to cast it to a an array of "cs_real_3_t" . The C language array/pointer arithmetic is quite limited, and can be tricky, though it is quite simple once you really understand it.

Best regards,

Yvan

[ximeng]

Dear Yvan,

Thanks! There is no compile error after the revision based on your suggestion. However it's stuck at the initialization stage as shown in the attachment. The simulation will not stop until I cancel it, but there is no output after the steps showing in the run_solver.log. Could you please have a see when you are available? Sorry for the bothering since I am still not very familiar with the coding currently.

Best regards,
Ximeng

[Yvan Fournier]

Hello,

I do not see any obvious error in your code, except that it does not handle parallel summation of values such as total_volume, total_enthalpy, or feedback_term.

Unless you sum those using a function such as cs_parall_sum (see examples), your code will be correct only as long as you run on a single MPI rank.

Best regards,

Yvan