-
Notifications
You must be signed in to change notification settings - Fork 175
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
Create JEDI class #2805
Create JEDI class #2805
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have any major comments here, but I'm worried that we may be missing something that would make this more generic. @DavidNew-NOAA do you think it is reasonable to try this for another app (snow, aero, soca) at this stage to see if the JEDI class is generic enough?
@CoryMartin-NOAA Sure, good idea. I haven't run any of those analyses in the past, but I'm willing to give them a try with the JEDI class. |
@DavidNew-NOAA there are CI test cases for all of the above (I think). I would suggest starting with snow DA as it is the simplest, then aero. Let me know if you need help setting up an experiment using the CI test case(s) |
@guillaumevernieres Feel free to take a look at what I've done here. I'm still in draft mode. Re: your comments on my previous (now closed) PR for context: That PR was based on the idea of an inheritance family tree like so: You mentioned that sometimes you want to run multiple JEDI applications in one set of tasks. It's a bit subtle, but in the case of AtmAnalysis, for example, that class only creates one JEDI object, but depending on whether I'm running the gdasatmanlvar job or the gdasatmanlfv3inc job, that JEDI object received a different |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good @DavidNew-NOAA and it makes more sense if it's meant to be used to create data members in our tasks rather than inherit a rigid framework. That should replace part of a utility module we currently use for our b-matrix job.
I can see how to use your work to cleanup the marine-da/soca b-matrix task and run multiple jedi applications ... but we're so far behind on so many other things that it probably won't happen for a while!
@DavidNew-NOAA , I am about to begin work on g-w issue #2415 in Do you recommend that I wait for this JEDI class PR to be merged into |
@RussTreadon-NOAA I still need Rahul's feedback, and he'a on leave, so I wouldn't wait. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I only reviewed jedi.py
as that sets the foundation for this PR. I am open to your (and others) thoughts on my comments.
…/global-workflow into feature/jedi_class
…ions to actual task
|
Build FAILED on Orion in Build# 4 with error logs:
Follow link here to view the contents of the above file(s): (link) |
Ignore Orion. Workflow in general doesn't work there yet. |
Automated global-workflow Testing Results:
|
The workflow does with the exception of cycling because the UPP submodule. It is being addressed in #2877 |
CI Passed on Hercules in Build# 3
|
All CI Test Cases Passed on Wcoss2:
|
49f697a
into
NOAA-EMC:develop
Thank you @WalterKolczynski-NOAA! |
* origin/develop: Create JEDI class (NOAA-EMC#2805) Restructure the bufr sounding job (NOAA-EMC#2853) Add an archive task to GEFS system to archive files locally (NOAA-EMC#2816) Reenable Orion Cycling Support (NOAA-EMC#2877) Eliminate race conditions and remove DATAROOT last in cleanup (NOAA-EMC#2893) Update aerosol climatology to 2013-2024 mean (NOAA-EMC#2888) Add ability to run CI test C96_atm3DVar.yaml to Gaea-C5 (NOAA-EMC#2885) Support global-workflow GEFS C48 on Google Cloud (NOAA-EMC#2861) Add 3 and 9 hr increment files to IC staging (NOAA-EMC#2876) Add diffusion/diag B for aerosol DA and some other needed changes (NOAA-EMC#2738) Correct ocean `MOM.res_#` stage copy (NOAA-EMC#2868) Support coupling on AWS (NOAA-EMC#2859) Add JEDI ATM lgetkf observer and solver jobs (NOAA-EMC#2833) Fix gdas build on Gaea and add Gaea to available CI list (NOAA-EMC#2857) Support ATM forecast only on Google (NOAA-EMC#2832) Add GEFS C48 support on AWS (NOAA-EMC#2818) Update omega calculation (NOAA-EMC#2751) Add snow DA update and recentering for the EnKF forecasts (NOAA-EMC#2690) support ATM forecast only on Azure (NOAA-EMC#2827) Convert staging job to python and yaml (NOAA-EMC#2651) Fixed test on UNAVAILBLE in python Rocoto check (NOAA-EMC#2842)
Description
This PR creates a PyGFS class called JEDI, which is to be instantiated everytime a JEDI application is run. The AtmAnalysis and AtmEnsAnalysis classes are no longer children of the Analysis class, but rather direct children of the Task class. They each have a JEDI object as an attribute, which is used to run either the variational/ensemble DA JEDI applications or the FV3 increment converter JEDI application, depending on which job they are created for (e.g. atmanlvar vs. atmanlfv3inc). The intention is that a later PR will apply this framework to all analysis task, and the PyGFS Analysis class will be removed.
Type of change
Change characteristics
How has this been tested?
This is just a draft as of right now.
Checklist