Skip to content
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

Split the soca run jjob #263

Closed
guillaumevernieres opened this issue Jan 6, 2023 · 6 comments
Closed

Split the soca run jjob #263

guillaumevernieres opened this issue Jan 6, 2023 · 6 comments
Assignees
Labels

Comments

@guillaumevernieres
Copy link
Contributor

guillaumevernieres commented Jan 6, 2023

Description

Isolate soca_var.x in one jjob only, move the other executables to a separate, dedicated jjob. Not ideal yet, but arguably closer to perfection!

Stuff to do

Create a new script in this repo and a new jjob in the g-w that will contain the JEDI executables in exgdas_global_marine_analysis_run.sh between L88 and L133

Suggested name for the script: exgdas_global_marine_analysis_bmat.sh ?

To be discussed with @AndrewEichmann-NOAA

@AndrewEichmann-NOAA
Copy link
Collaborator

@guillaumevernieres So are we shooting for all of the APRUN calls to have their own scripts?

@AndrewEichmann-NOAA
Copy link
Collaborator

The goal for now will be to split the soca_var.x executable call from the previous ones, so that it has its own script and j-job that runs in the current workflow-enabled ctests within GDASApp, with the eventual goal of having separate tasks within the rocoto workflow.

@AndrewEichmann-NOAA
Copy link
Collaborator

Partially addressed by #272

@AndrewEichmann-NOAA
Copy link
Collaborator

@guillaumevernieres Do we want a separate g-w config file for JGDAS_GLOBAL_OCEAN_ANALYSIS_BMAT, either now or in the future? Right now it does fine with configs="base ocnanal ocnanalrun", and I don't know how strictly the g-w people would want a separate one. With EFSOI there was some resistance to a proliferation of config files.

@guillaumevernieres
Copy link
Contributor Author

@guillaumevernieres Do we want a separate g-w config file for JGDAS_GLOBAL_OCEAN_ANALYSIS_BMAT, either now or in the future? Right now it does fine with configs="base ocnanal ocnanalrun", and I don't know how strictly the g-w people would want a separate one. With EFSOI there was some resistance to a proliferation of config files.

It's probably OK for now @AndrewEichmann-NOAA . Your j-job will use the same resources as the "run" j-job, but the completion time should be a lot less than running the DA, that's the one difference that I can think of ... I'm sure I'm missing something, but that can be pushed down to your next PR that will add the dependencies of that j-job.

WalterKolczynski-NOAA pushed a commit to NOAA-EMC/global-workflow that referenced this issue Jan 23, 2023
Adds jjob for ocean analysis bmat. The intent is to have separate tasks for the ocean analysis and generation of the b matrix. Once this is merged, additional modifications will be made to GDASApp to allow it to be run with the other global-workflow components of ocean/ice DA

Refs: NOAA-EMC/GDASApp#263
@guillaumevernieres
Copy link
Contributor Author

Thanks @AndrewEichmann-NOAA ... better you than me :)
Done so closing.

WalterKolczynski-NOAA pushed a commit to NOAA-EMC/global-workflow that referenced this issue Jan 31, 2023
This adds the ocnanalbmat task to S2S workflow between ocnanalprep and ocnanalrun.

At present this is a stub task that does not actually run the associated jjob, pending more extensive testing

Partially addresses NOAA-EMC/GDASApp#263
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants