streamwise periodicity
Forum rules
Please read the forum usage recommendations before posting.
Please read the forum usage recommendations before posting.
-
- Posts: 4125
- Joined: Mon Feb 20, 2012 3:25 pm
Re: streamwise periodicity
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
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
- Attachments
-
- cs_user_source_terms.c
- (9.62 KiB) Downloaded 232 times
Re: streamwise periodicity
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
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
-
- Posts: 4125
- Joined: Mon Feb 20, 2012 3:25 pm
Re: streamwise periodicity
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
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
Re: streamwise periodicity
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
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
- Attachments
-
- run_solver.rar
- (1.27 MiB) Downloaded 171 times
-
- setup_Ri-0.19_XYperiodic_symmTop.xml
- (171.21 KiB) Downloaded 155 times
-
- cs_user_source_terms_ximeng.c
- (9.61 KiB) Downloaded 176 times
Re: streamwise periodicity
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
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
- Attachments
-
- cs_user_sink_term.c
- (2.87 KiB) Downloaded 161 times
-
- Posts: 4125
- Joined: Mon Feb 20, 2012 3:25 pm
Re: streamwise periodicity
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
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
Re: streamwise periodicity
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
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
- Attachments
-
- compile_error.txt
- (1.8 KiB) Downloaded 146 times
-
- cs_user_sink_term.c
- (3.34 KiB) Downloaded 148 times
-
- Posts: 4125
- Joined: Mon Feb 20, 2012 3:25 pm
Re: streamwise periodicity
Hello,
You need to replace:
With:
Or the equivalent:
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
You need to replace:
Code: Select all
const cs_real_3_t centroid = domain->mesh_quantities->cell_cen[i];
Code: Select all
const cs_real_t *centroid = &(domain->mesh_quantities->cell_cen[i*3]);
Code: Select all
const cs_real_t *centroid = domain->mesh_quantities->cell_cen +(i*3);
Best regards,
Yvan
Re: streamwise periodicity
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
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
- Attachments
-
- run_solver.log
- (32.13 KiB) Downloaded 151 times
-
- cs_user_sink_term.c
- (3.35 KiB) Downloaded 146 times
-
- Posts: 4125
- Joined: Mon Feb 20, 2012 3:25 pm
Re: streamwise periodicity
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
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