SeisFlows Code Development Plan #6
bch0w
started this conversation in
Development
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This Code Development Plan (CDP) supersedes the CDP on the documentation and lays out the roadmap of features that are needed, requested or desired by the users and developers, as well as known bugs that should be fixed.
New developers who are interested in looking for tasks can use this list to determine what the needs of the community are. Development plans are organized by sections and modules for easier accessibility.
If you are interested in taking on a task and require more information to tackle it, feel free to either comment here with the task and a request for more details, or open an issue (https://github.com/adjtomo/seisflows/issues) with the task. Relevant issues will be linked back to this document for tracking purposes.
Note that any changes implemented in this list will likely go to the
devel
branch and be released officially in periodic version releases.Priority of tasks are denoted by:
Difficulty for tasks are denoted by:
e.g., ❗🐣 means this is easy but needs to be addressed ASAP!
Unsorted:
Things on our radar
Known Bugs
Issues that have been pointed out by Users/Developers that should be fixed prior to implementing anything new
seisflows clean
does not remove the directory included inpath_data
ntask_max
mechanisms (system parameter ntask_max is not honored for certain subclasses seisflows#200)unit_output
does not show up in parameters.yaml file during configure, but it shouldntask_max
, though it is included in the parameter setPlanned Features
Big planned feature additions that may require modifying some of SeisFlows' internal structure
simultaneous_runs
feature to improve storage requirements for large runsPackage/Version Control/GitHub
Package Structure
Namespace Changes
ntask
->nevents
because ntask can get confused with System parametersdefault
preprocessing module, sort of confusing w.r.t e.g., default parametersDocumentation/Logging:
Updates or changes to the documentation on ReadTheDocs
How Tos
Parameter File
Logging (sflog.txt):
seisflows check
should log out what checks are being run and whether or not they pass, so that Users know what parts of the code are being checked (less black boxy)Module Upgrades
Specific changes, updates or additions to individual modules with the package
Workflow:
iteration
, not really necessary if Thrifty behavior is fixedSolver:
parameters
, e.g., explicitely naming the updated parameters (vp, vs), rather than putting this behind names (acoustic, elastic), or bothgenerate_data
Preprocessing:
System:
rerun
ignored if all jobs failed because clearly something is wrong with the function setupsubmit_to
== 'direct' (or 'login') submit master job directly to login node. This can currently be achieved withseisflows submit --direct
ntasks
job fail, kill the main job. This should signify that something is wrong and the System should not attempt to rerun failed jobs or continue the workflowOptimize
SeisFlows Command Line Tool
seisflows state
for editing the State file so that Users don't have to manually edit itseisflows check
should have a thumbs up when all checks passseisflows unset
reset parameter in parameter file to its default valueseisflows clean --limited
do not do a full clean but only delete largest scratch files for storage savingsseisflows reset line_search
should save the old line search files somewhere incase this needs to be undoneBeta Was this translation helpful? Give feedback.
All reactions