You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The first line points to an "options" directory that contains further input files (e.g. RELEASES, CONTROL, etc.). The second line points to the output directory that would contain the header output netcdf or fortran binary files.
This proposal for a new standard workflow suggests pointing to the pathnames file to initiate reflexible. It is not required (e.g. we should maintain the possibility to do H = rf.Header(... but, it could be an improvement is folks work flow started with the pathnams file.
As we are now implementing a read_releases class, this could be done as R = rf.Releases('/path/to/release_file').
However, integrating this into a full reflexible workflow might look something like:
In doing this, we should evaluate to some extent what information on the header (which now comes entirely from the output files), should be taken from input files (e.g. CONTROL file). And whether, in fact, we should conduct some consistency tests and raise a warning if the output file is not consistent with the input file...
The initiation could, for example, probably create most of the Header from the CONTROL file (see legacy.pflexible for a read_control example). Then, while instantiating, it could check if there is any output created, or if the directory is empty (or maybe doesn't even exist) and provide a warning:
Currently the workflow for reflexible is as a post processing tool for FLEXPART:
When flexpart runs, it initially reads a single file called
pathnames
with the following structure:The first line points to an "options" directory that contains further input files (e.g.
RELEASES
,CONTROL
, etc.). The second line points to the output directory that would contain the header output netcdf or fortran binary files.This proposal for a new standard workflow suggests pointing to the pathnames file to initiate reflexible. It is not required (e.g. we should maintain the possibility to do
H = rf.Header(...
but, it could be an improvement is folks work flow started with the pathnams file.As we are now implementing a read_releases class, this could be done as
R = rf.Releases('/path/to/release_file')
.However, integrating this into a full reflexible workflow might look something like:
In doing this, we should evaluate to some extent what information on the header (which now comes entirely from the output files), should be taken from input files (e.g. CONTROL file). And whether, in fact, we should conduct some consistency tests and raise a warning if the output file is not consistent with the input file...
The initiation could, for example, probably create most of the Header from the CONTROL file (see
legacy.pflexible
for aread_control
example). Then, while instantiating, it could check if there is any output created, or if the directory is empty (or maybe doesn't even exist) and provide a warning:The text was updated successfully, but these errors were encountered: