streamwise periodicity

[ximeng]

Hi Yvan,

Thanks for your feedback. I've made some revisions to the heat sink term code. Please find the latest version attached. The code works but the results are wrong.

I use the following two lines (line 30-31) to get the temperature at the current time step and the previous time step.
const cs_real_t *cvar_temp = CS_F_(t)->val;
const cs_real_t *cvara_temp = CS_F_(t)->val_pre;

And I use lines 64-68 to get the sum of the parallel ranks:
if (cs_glob_rank_id >= 0) {
cs_parall_sum(1, CS_REAL_TYPE, &total_volume);
cs_parall_sum(1, CS_REAL_TYPE, &total_enthalpy);
cs_parall_sum(1, CS_REAL_TYPE, &total_enthalpy_prev);
}

However, I'm encountering incorrect output results. When I print the values of total_enthalpy (current time step), total_enthalpy_prev (previous time step), and feedback_term (heat sink term) at each iteration, the results are not as expected. The feedback_term consistently equal to 0, and total_enthalpy remains equal to total_enthalpy_prev. I have attached the run_solver.log file for your review.

If I exclude lines 64-68, which are for parallel sum computation, all three variables (total_enthalpy, total_enthalpy_prev, and feedback_term) output as 0. (For the actual simulation, I use 2048 processors).

I use code_saturne v7.0. And I haven't find any errors in my code currently. It would be very appreciate if you could provide some insights or suggestions when you are available based on the wrong outputs.

Best regards,
Ximeng

[Yvan Fournier]

Hello,

If you exclude the parallel sum, the values you print are those of MPI rank 0. So if none of the cells assigned to rank 0 (depending on the automatic partitioning) are in the selected region, it is normal to have 0.

When you add the parallel sums, do you obtain expected values at least for the total volume ?

There could be an issue with the selection if the mesh is shifted/not at the expected coordinates.

Otherwise, is the enthalpy or temperature > 0 ? If not, the test line 73 will avoid the feedback term computation.

And are you solving with enthalpy or temperature ? If you are solving for temperature, you may want to rename references to enthalpy. If you are solving for Enthalpy, then temperature is a property, not asolved variable, so source terms should apply to enthalpy instead.

Regards,

Yvan

[ximeng]

Hi Yvan,

Thanks for your prompt feedback!

When I add the parallel sums, I obtain expected values for the total volume as shown in the run_solver.log.

"feedback_term: 0.000000e+00 total_enthalpy: 1.529331e+02 total_enthalpy_prev: 1.529331e+02 total_volume: 5.237434e-01"

The total volume 5.237434e-01 is right, corresponding to my selected area volume (1*0.75*0.7=0.525).
The total enthalpy is 1.529331e+02 (> 0), approximately 0.525*292K (the total volume*the reference air temperature). It seems to be reasonable but it doesn't change. It just keep the same value with time step increasing, and equal to the previous time step total enthalpy.

For the final point, I think I solve for the temperature since I choose Thermal model-Thermal scalar-Temperature(Kelvin) as shown in the picture and setup.xml. And What you mean "If you are solving for temperature, you may want to rename references to enthalpy." I think in my code, I use temperature* volume to get the enthalpy, and then use feedback_term=delta_enthalpy/total_volume to get the feedback_term. So the feedback_term is acctually for temperature. It should be right I think. Is this what you mean? Thanks!

Best regards,
Ximeng

[Yvan Fournier]

Hello,

Yes, you seem to be using the standard temperature resolution.

Do not forget that for enthalpy, you also need to multiply by density and CP. If this is missing your sink term might simply be too small ?

What are the other factors (boundary and initial conditions) influencing enthalpy here ?

Best regards,

Yvan

[ximeng]

Hi Yvan,

Thanks for your reply.

One point is that It might not related to the code now. The delta enthalpy might be actually really small (might be 0) between two consecutive time steps (since the temperature condition is just two different constant values for ground and air, no heat emission). So I plan to calculate the delta enthalpy between maybe 10 time steps or 100 time steps. So now the problem is that I just know that we could get the field in the last time step use "const cs_real_t *cvara_temp = CS_F_(t)->val_pre;". But how can we get the field in last 10 or 100 time step? Could you provide any examples or guidance on this matter? Thanks!

Best regards,
Ximeng

[ximeng]

Hi Yvan,

Sorry for the bothering. But there are something wrong in my last post. I have confirmed that the actual delta enthalpy is not 0 between two consecutive time steps. The following are two consecutive time steps outputs in the run_solver.log:

time step 1: feedback_term: 0.000000 total_enthalpy: 211.720959 total_enthalpy_prev: 211.720959 total_volume: 0.725000
time step 2: feedback_term: 0.000000 total_enthalpy: 211.720987 total_enthalpy_prev: 211.720987 total_volume: 0.725000

It is obvious that 211.720959 is not equal to 211.720987, but the extracted total enthalpy equal to the total_enthalpy_pre through the cs_user_sink_term.c code. Therefore, the problem is that the code didn't get the correct previous time step temperature through " const cs_real_t *cvara_temp = CS_F_(t)->val_pre;" (it returns the same value as the current time step temperature). The val_pre is based on the general documentation: https://www.code-saturne.org/documentat ... 75076f0a29

Are there any examples available for retrieving field variables(such as temperature or others) from the last or previous several time steps?

Best regards,
Ximeng

[Yvan Fournier]

Hello,

There are some user examples in.the documentation but they may not be sufficient.

When.the code starts a new time step, the current value is copied into val_pre and the new value is computed.
What I suspect is happening in your case is that when the source term user-defined function is called, since we are in the process of computing the new temperature value, val_pre has already been overwritten but the new value not yet updated, so they are identical..

There are 2 possible workarounds for this:
- Add a user postprocessing field in the GUI, and in cs_user_extra_operations, copy the previous temperature value to that field'val array the use that val array instead of the température's val_pre.
- In cs_user_parameters, call cs_field_set_n_time_vals to assign 3 time values instead of 2 for the temperature. In your test you can the use temperature->vals[2][cell_id] instead of temperature->val_pre[cell_id].

Answering this post from my phone, so sorry if there are typos and less detail..

Best regards,

Yvan