output velocity data at each time step from the cell centers

[ximeng]

Hi team,

I need to output velocity data at each time step from the cell centers in my simulation (saved to separate files instead of output through postprocessing folder to avoid large postprocessing results). I've used the attached cs_user_extra_operation.c file to handle this, but the outputs appear incorrect. Specifically:

1) Duplicate Cell IDs with Different Coordinates: In the cell_centers.dat output, the same cell ID appears with varying coordinates, which shouldn't happen. like: (time step | cell id | x | y | z)
"1 1 8.266212e-01 4.220800e-01 9.565712e-02
1 2 8.266212e-01 4.220800e-01 9.679760e-02" and
"1 1 8.000000e-01 3.750000e-01 8.000000e-04
1 2 8.000000e-01 3.750000e-01 1.460000e-03"

2) Incorrect Velocity Data: This issue with cell IDs and coordinates seems to also affect the velocity_u.dat file.

I'm not sure where the error is in my code. Could you please help me review it to identify the cause? Or, if there's a more direct or reliable way to output the velocity data at each time step from cell centers, I'd appreciate any suggestions. Thank you!

Best regards,

[Yvan Fournier]

Hello,

Are you running on a single processor ? Your code will definitely not work correcty when using MPI parallelism.

Best regards,

Yvan

[ximeng]

Hi Yvan,

Thanks for your suggestion! I’ve revised the code in parallel way to output cell volume for a specific zone at each time step (the attached code focuses on cell volume; a similar approach would apply to velocity). I’m using cs_parall_allgather_r to gather cell volume data across all ranks and print the results, but I encountered an error indicating that the sum of local counts does not match the global count. I’ve tried using the global count from cs_parall_allgather_r, as well as the direct value 78213 from cs_parall_sum that I calculated before this section. However, the error message consistently reads:

cs_parall.c:861: Fatal error.
Incorrect arguments to cs_parall_allgather_r:
sum of arg. 1 (n_elts) on ranks is not equal to arg. 2 (n_g_elts).
Call stack:
1: 0x150c10b8ec02 <cs_parall_allgather_r+0x222> (libsaturne-7.0.so)
2: 0x45f115 <cs_user_extra_operations+0x455> (cs_solver)
3: 0x150c10ae6fa9 <caltri_+0x1d1f> (libsaturne-7.0.so)
4: 0x150c11b74cbc <main+0x6ec> (libcs_solver-7.0.so)
5: 0x150c0916a29d <__libc_start_main+0xef> (libc.so.6)
6: 0x40227a <_start+0x2a> (cs_solver)
End of stack

Could you please take a look when you have a moment? I’d really appreciate your help.

Best regards,

[Yvan Fournier]

Hello,

You are computing g_ii before filtering the cells in the zones, so your counts can't match.

Also, if you open your file on al ranks, you may have multiple issues.

Do you need to do this once or twice or automate it ? You could probably do all of this easily in ParaView, selecting a zone in a box, and outputting to a spreadseat view, and exporting the spreadsheet to csv (the "export spreadsheet" button is at the top right of the spreadsheet view).

Best regards,

Yvan

[ximeng]

Hi Yvan,

Thank you for your reply. I’m only using g_ii to display the total cell count across the entire domain, and it’s not used in any subsequent code or output, so I don’t think it’s related to the error. I removed this section and kept only a single output file, the same error still occurs. is cs_parall_allgather_r suitable to do this work?

To clarify why I need this approach instead of using Paraview:
1) I need to output the results at every time step (or at most every 100 steps), resulting in around 10,000 snapshots. Exporting velocity data through Paraview this many times, even with macros, is not efficient.
2) Storing such a large dataset in the postprocessing folder would be very large.

Best regards,
Ximeng

[Yvan Fournier]

Hello,

It still seems you are opening "output.log" and looping on the global count with no filter on the MPI rank doing this operation. And the global count (parallel sum) bfore the call to cs_parall_allgather_r is commented. Unless I missed something, since you code indentation is inconsistent/confusing and a lot of the code is commented, which make proofreading more difficult.

Regards,

Yvan