Use more cycledefs for task control

[WalterKolczynski-NOAA]

Description
Splits the existing rocoto cycle definitions up to offer better job control. This means that only the jobs that are due to run will appear in a cycle's job list from rocotostat/rocotoviewer. It also allows for the removal of some of the cycleexist dependencies that were there solely to prevent the job from running in the half cycle. A side effect of this change is that the half-cycle will be recognized as a completed cycle, fixing the bug with archive jobs starting in the fourth cycle (#1003).

The gdas cycledef has been split into a gdas_half for the first half- cycle and gdas for the other GDAS cycles. Tasks that run during that first half-cycle therefore run on two cycledefs.

For gfs, instead of slicing perpindicular to time, a new cycledef gfs_cont (continuity) was created in parallel to the existing gfs cycledef that omits the first cycle. This was done since only one job (aerosol_init) currently skips the first cycle, and this prevents the need to provide two cycledefs for every gfs task but one.

Since some time math is now being done on sdate in workflow_xml.py, we now keep those as datetime objects and only convert to string when writing the cycledef strings.

In order to access the pygw utilities in the workflow directory, a symlink is created in workflow pointing to the pygw location in ush. A better solution may be found in the future.

Fixes #1003

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

• 4½-cycle cold-start C96/48 cycled test on Orion
• 4½-cycle warm-start C384/192 cycled test on Orion
• Coupled prototype test on Orion
• 3-cycle forecast-only C96 ATMA test on Orion (test aerosol_init)
• GDASapp

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings
• New and existing tests pass with my changes

[WalterKolczynski-NOAA]

Will need some help confirming that the GDASapp job flow is still correct, since I don't know how to test that app myself.

I'd also love some confirmation testing on all the other modes. I tried to hit everything that might matter for these changes.

[aerorahul]

The gfs_cont is meant to represent "continuous aerosols". In other words, it is no longer a "parallel" forecasts, but is now "sequential" since every subsequent CDATE depends on the aerosol backgrounds (restarts) from the forecast valid at the CDATE initialized from the previous CDATE.

In that frame, the continuous aerosols operates like the "cycled" system which is sequential.

[CoryMartin-NOAA]

The gfs_cont is meant to represent "continuous aerosols". In other words, it is no longer a "parallel" forecasts, but is now "sequential" since every subsequent CDATE depends on the aerosol backgrounds (restarts) from the forecast valid at the CDATE initialized from the previous CDATE.

In that frame, the continuous aerosols operates like the "cycled" system which is sequential.

Yeah I guess that is a confusing name then... This is really a temporary thing though so I won't fight it, as the 'aerosol init' will be replaced by aerosol DA soon.

[aerorahul]

The gfs_cont is meant to represent "continuous aerosols". In other words, it is no longer a "parallel" forecasts, but is now "sequential" since every subsequent CDATE depends on the aerosol backgrounds (restarts) from the forecast valid at the CDATE initialized from the previous CDATE.
In that frame, the continuous aerosols operates like the "cycled" system which is sequential.

Yeah I guess that is a confusing name then... This is really a temporary thing though so I won't fight it, as the 'aerosol init' will be replaced by aerosol DA soon.

@CoryMartin-NOAA
There will still be those who wish to run continuous aerosols without DA. I can't say why they would want to (perhaps cost savings from not having to run DA), but there will be some who would argue for such capability. In essence, continuous aerosols is "Identity DA".

[CoryMartin-NOAA]

@aerorahul not disagreeing there. I guess my point is, why is it a separate 'GFS' and not just an option to turn on/off?

[CoryMartin-NOAA]

gfs_cont is less than ideal but otherwise seems fine to me

[WalterKolczynski-NOAA]

@CoryMartin-NOAA did you test to make sure I didn't break the GDASapp?

[CoryMartin-NOAA]

@WalterKolczynski-NOAA I have not yet. To be honest, it is only used by like 2-3 people at the moment so I wouldn't worry too much about breaking GDASApp compatibility at this time, since all of our stuff is definitely still in flux. In my opinion, don't let us hold you up (unless @guillaumevernieres or @RussTreadon-NOAA want to make sure it works before merging)

[guillaumevernieres]

@WalterKolczynski-NOAA I have not yet. To be honest, it is only used by like 2-3 people at the moment so I wouldn't worry too much about breaking GDASApp compatibility at this time, since all of our stuff is definitely still in flux. In my opinion, don't let us hold you up (unless @guillaumevernieres or @RussTreadon-NOAA want to make sure it works before merging)

I'm with @CoryMartin-NOAA , you don't need to worry about the GDASApp stuff.

[WalterKolczynski-NOAA]

@WalterKolczynski-NOAA I have not yet. To be honest, it is only used by like 2-3 people at the moment so I wouldn't worry too much about breaking GDASApp compatibility at this time, since all of our stuff is definitely still in flux. In my opinion, don't let us hold you up (unless @guillaumevernieres or @RussTreadon-NOAA want to make sure it works before merging)

I'm with @CoryMartin-NOAA , you don't need to worry about the GDASApp stuff.

Okay. It's a simple change later if anything is wrong, I just hate breaking things (I do enough of that unknowingly).