[NotOverUnderated]

Hi,

I am using OpenFOAM v2306. I wonder if there is a function object that can do the following:

• Can save fields (e.g., U, p, etc.) under a different path (by default the fields are saved under time directories). I need the fields to be saved in a different path and MUST be in OpenFOAM file format (to be able to restart the simulation if needed from those files, this is very important for me), and to automate the backup of the simulations to other locations.

There are some function objects that can save the the fields already in other formats such as vtk under a custom path. But that's something else because it is not guaranteed that you can convert these fields back to the native OpenFOAM format.

Why?

Imagine this scenario: You are running a simulation on an HPC system in a filesystem that deletes files every 20 days and you have a very limited storage on it, so you must use purgeWrite to write only, say, the last three time steps. But on the other hand you have another location on the HPC system where you can save permanently your files but you are not allowed to run simulations on it.

Now, if OpenFOAM allows somehow via a function object, an easy way to write the fields in OpenFOAM file format but under a different path that would be very convenient. I can then use purgeWrite to save only the last 2 or 3 time steps but I am saving the fields to another location for backup.


Is this already possible to do in OpenFOAM without some ugly workarounds?

[Yann]

I don't think there is a function object doing what you want out of the box, but you could use the systemCall function object to execute shell commands or a script in order to move data where you want.

https://develop.openfoam.com/Develop...ref_type=heads

Regards,
Yann

[NotOverUnderated]

Originally Posted by Yann

I don't think there is a function object doing what you want out of the box, but you could use the systemCall function object to execute shell commands or a script in order to move data where you want.

https://develop.openfoam.com/Develop...ref_type=heads

Regards,
Yann

Hi Yann!

Thank you very much for your suggestion.

I have used systemCall many times, but unfortuantely I consider it for this specific task of saving openfoam files, under the category of "ugly workarounds" since it is not reliable. What I consider as ugly workaround as well is the use of "coded" function object because it is hard to maintain. I prefer to use simple function objects that simply work and do a very specific task well.

I do really hope the writeObjects function object implements a new keyword, something like "directory" that allows specifying the output path of the written fields.

[Yann]

Originally Posted by NotOverUnderated

I have used systemCall many times, but unfortuantely I consider it for this specific task of saving openfoam files, under the category of "ugly workarounds" since it is not reliable.

Why do you think it is not reliable?

Originally Posted by NotOverUnderated

I do really hope the writeObjects function object implements a new keyword, something like "directory" that allows specifying the output path of the written fields.

I doubt it will ever happen since the OpenFOAM philosophy is to keep all data inside the case directory. I cannot think of any feature in OpenFOAM which write things elsewhere than case directory.
But maybe you can try suggesting a feature request in the bug tracker.

[Tobermory]

You could come at it from a different direction ... instead of trying to do it within the OF run, you could launch a shell script that spends most of its time sleeping, but once an hour, say, it wakes up, checks for files older than e.g. 1 day and then moves them to your safe space. You'll find that shell commands find and sleep will help here. Then, you just need to launch this shell script along side your OpenFOAM run ... indeed it can run on any server that has rw access to the two file systems - it doesn't have to run on the HPC server.

[NotOverUnderated]

Originally Posted by Yann

Why do you think it is not reliable?

This is because it will come with a plethora of issues: you need to run shell scripts, which does not feel native. Also I usually use Windows version of OpenFOAM, you can imagine how tricky it becomes to write shell scripts and ensure they will run correctly. In the script you must ensure to handle all the writing correctly: the write interval, the restarting of the simulation, ...... things become increasingly complex without justification. A simple control behind a function object will abstract away all these issues.

I cannot think of any feature in OpenFOAM which write things elsewhere than case directory.

There are function objects that can write fields to a custom path, such as vtkWrite and ensightWrite function object. Other function objects such as surface sampling can write vtk/ensight files under postProcessing folder (Yes those are slices and are not true 3D fields, but at least that's close).

[NotOverUnderated]

Originally Posted by Tobermory

You could come at it from a different direction ... instead of trying to do it within the OF run, you could launch a shell script that spends most of its time sleeping, but once an hour, say, it wakes up, checks for files older than e.g. 1 day and then moves them to your safe space. You'll find that shell commands find and sleep will help here. Then, you just need to launch this shell script along side your OpenFOAM run ... indeed it can run on any server that has rw access to the two file systems - it doesn't have to run on the HPC server.

Thank you for taking the time to reply. I appreciate it.

Unfortunately, as I stated above, I have thought about using shell scripts but I find them not suitable, due to the complexity required to handle many scenarios. Using an external shell is not obvious, how do you ensure it will keep running for long time? even if I use tmux, this is not guaranteed and I will find myself doing sysadmin tasks that are beyond my skills.

Another trick is to use coded function object, creating duplicate fields from references of the existing fields, hardcoding the custom path. This probably much better than using a shell script but I personally tend to keep things simple. That's why I am looking for a simple solution.