Dear Elmer community,
I am quite new to Elmer, with some experience in CFD and Heat transfer problems (Conjugate heat transfer).
I would be thankful for any advices if and how it would be possible to merge parallel (MPI) run restart *.result.* files into one
file such that the post processing run, which is essentially only doing "SaveData" "SaveScalars", could be run in serial mode (one processor/core only).
Many thanks for all constructive ideas!
-Petri
Merge mpi result files for a serial run
-
- Site Admin
- Posts: 4826
- Joined: 22 Aug 2009, 11:57
- Antispam: Yes
- Location: Espoo, Finland
- Contact:
Re: Merge mpi result files for a serial run
Hi Petri,
The *.result file does not include the full information of the mesh. Hence it is difficult to merge the partitioned result files. The main usage of result file is in restarting for good initial guess or to continue from some previous time instance.
The recommended postprocessing format is *.vtu file (xml based unstructured vtk format). There in parallel the *.pvtu file is a wrapper to the individual files and Paraview (and other VTK based visualization tools) knows how to handle this.
SaveScalars and SaveLine are the only ones that do parallel reduction if requested. These are reduced dimensional routines and hence the amount of data remains reasonable. Also the Elmer/Ice community uses a lot the NetCDF format where parallelism is supported in some way.
The old visualization format for ElmerPost, *.ep. Has also some hack to merge results from different MPI nodes into one big file. This is done by "ElmerGrid 15 3 case.ep". ElmerPost is more or less obsolite because of Paraview but some people may still use the *.ep format since it is pretty straight-formard to read. Be aware though that elemental (cell) and dg values are not much supported here and we have no plans to further develop *.ep format.
-Peter
The *.result file does not include the full information of the mesh. Hence it is difficult to merge the partitioned result files. The main usage of result file is in restarting for good initial guess or to continue from some previous time instance.
The recommended postprocessing format is *.vtu file (xml based unstructured vtk format). There in parallel the *.pvtu file is a wrapper to the individual files and Paraview (and other VTK based visualization tools) knows how to handle this.
SaveScalars and SaveLine are the only ones that do parallel reduction if requested. These are reduced dimensional routines and hence the amount of data remains reasonable. Also the Elmer/Ice community uses a lot the NetCDF format where parallelism is supported in some way.
The old visualization format for ElmerPost, *.ep. Has also some hack to merge results from different MPI nodes into one big file. This is done by "ElmerGrid 15 3 case.ep". ElmerPost is more or less obsolite because of Paraview but some people may still use the *.ep format since it is pretty straight-formard to read. Be aware though that elemental (cell) and dg values are not much supported here and we have no plans to further develop *.ep format.
-Peter
Re: Merge mpi result files for a serial run
Dear Peter,
Thank you for the reply and suggestions.
I think I've figured out correctly the output format of the parallel runs.
My problem was to find the line average of the resulting temperature (and velocities) on a (semi)-circle arc with "SaveData" "SaveLine". The routine produces a variable number of files for a variable number of total 32 processors/cores, probably depending on the "Circle Divisions" parameters of the "Circle Coordinates" and also the circle position etc. It seems that it is enough to merge these files, at least the results make sense.
I did try the parallel reduction for other outputs (boundary average) but it did not work / not implemented for this case. Hence, I thought it would not work either with the circle interpolation.
Thank you again,
-Petri
Thank you for the reply and suggestions.
I think I've figured out correctly the output format of the parallel runs.
My problem was to find the line average of the resulting temperature (and velocities) on a (semi)-circle arc with "SaveData" "SaveLine". The routine produces a variable number of files for a variable number of total 32 processors/cores, probably depending on the "Circle Divisions" parameters of the "Circle Coordinates" and also the circle position etc. It seems that it is enough to merge these files, at least the results make sense.
I did try the parallel reduction for other outputs (boundary average) but it did not work / not implemented for this case. Hence, I thought it would not work either with the circle interpolation.
Thank you again,
-Petri