-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve postprocessing #147
Comments
postProcessing/minMax_U/<time_>/fieldMinMax.dat
postProcessing/forces/<time_>/force.dat
|
postProcessing/sample_cuttingLine/<time_>/<type_>_<name_>_<var1_>_<var2_>_<var3_>.xy (e.g. line_h-wake-survey-1_nut_p_U.xy), one file per unique name
|
postProcessing/solverInfo/<time_>/solverInfo.dat
postProcessing/forceCoeffs/<time_>/coefficients.dat
postProcessing/probes/<time_>/<varname_> (e.g. U or p)
|
OK let's start with implementing a parser for the probes in Owls. From this we will derive a generic parse for the body (which is a simple pandas/numpy csv parser) and a separate parser for the different header. The header parser allows to get and later set the column names. In a later step we will work on an automatic detection of the format, either by name/folder or the header structure. |
Motivation
This issue collects requirements to add further support for post-processing of OF postProcessing folder. Inside the postProcessing folder we usually find multiple .dat files stored in a subfolder named after the probe or function which generates the file and a time subfolder for the first time step at which the file is created. The data files itself are not standardized and could be in different formats.
Goal
The goal of OBRs post-processing functionality is automated reading and parsing of OpenFOAMs unstructured simulation artifacts like log files and probes and sample data in the postProcessing folder. After OBRs post-processing step, the post-processed data should be accessible as python data structures (ideally records) via OBRs query functionality for further processing like plotting etc.
Approaches
Currently, we have several postprocessing strategies:
obr run -o apply <path/to/postproscript.py>
obr status
Explicit approach
In the explicit approach 1. a handle to all (not filtered) workspace folders is given to the user. The user can use convenience functions to perform the post-processing (eg. access to the statepoint, job_document, owls functions for log and file parsing. The user is responsible for writing the post processing script them self. Improving this approach means:
postPro.register(minMaxU, forceCoeffs ...)
obr apply <path/to/postproscript.py>
shortcut?Implicit approach
The implicit approach is used for standard information one can extract from a simulation. Eg.: current time-step, next write to disk ...
Related
This Issues is also related to changing obr status output.
The text was updated successfully, but these errors were encountered: