Organize run directory

[WalterKolczynski-NOAA]

Description

The run directory is unwieldy. While a few things (like FV3 restart files) have their own subdirectory, most files are just placed in one big flat structure mixing input files, config files, log files, and output files from every component. This can create a directory with thousands of files, making it difficult to navigate or find any particular file. The incoming aerosol component only adds to this problem.

Solution

I'd like to see the run directory organized so that most files are placed in an appropriate subdirectory: one for PET logs, one for fix files, one for input data, and one output directory for each component. Keep only the regular log and input namelist/configure files at the top level.

Alternatives

Other hierarchies than the one suggested are possible, as long as files are no longer mixed together in one big directory.

[climbfuji]

This is a good idea, although it may require some code changes (the ozone physics for example have hardcoded paths to the input files, which they shouldn't - maybe a good chance to clean that up). I would like to take this further and suggest that once we come up with a clean directory layout, we will require every workflow as well as the regression testing system to produce exactly such a directory structure.

[JessicaMeixner-NOAA]

For WW3 we have an issue to write the restart files into a directory NOAA-EMC/WW3#219 in a general way to retain the capability which was hard-coded in the v16 branch. I like the idea of extending it for all the types of input/output for waves (and the other components).

For the models that use FMS, separating the input files from the INPUT directory was not possible a few years ago. I think there was a bug perhaps for this (or user error). But since both the atm and ocean use input.nml some of that might be hard to split out.

[DeniseWorthen]

There is a varying level of blame among the components regarding this issue. The main offender I've noticed recently is ATM, since we now have 6 input files for each of the fixed files when running noahmp. In the RTs, these files are set using the namsfc. Is it possible to define the entries there w/ a preceding "INPUT/" directory name?

[junwang-noaa]

I think we need to discuss more in the output structure, otherwise the INPUT directory will be as messy as the current run directory as both atm and ocn input files are there, and now we will have fixed files go under it. Also if ww3 has issues to write restart files in a separate directory, where ww3 restart files go?

…

On Wed, Jun 9, 2021 at 11:39 AM Denise Worthen ***@***.***> wrote: There is a varying level of blame among the components regarding this issue. The main offender I've noticed recently is ATM, since we now have 6 input files for each of the fixed files when running noahmp. In the RTs, these files are set using the namsfc. Is it possible to define the entries there w/ a preceding "INPUT/" directory name? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#631 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI7D6TLOMADJB7EFXGGGGV3TR6DI7ANCNFSM46MIKFQQ> .

[WalterKolczynski-NOAA]

If input files are also a big concern, one solution would be for each component to have its own directory with input, output, and restart directories.

I agree this is probably going to have to reach down into the individual components. Likely straightforward once a target structure is determined, but tedious and requiring coordination.

[SMoorthi-emc]

Dom, It is not hard coded; you can always link in your script which is what I do. By the way, in my own scripts I have different directories for different component history and restart files, which also take advantage of links.. Moorthi

…

On Wed, Jun 9, 2021 at 11:25 AM Dom Heinzeller ***@***.***> wrote: This is a good idea, although it may require some code changes (the ozone physics for example have hardcoded paths to the input files, which they shouldn't - maybe a good chance to clean that up). I would like to take this further and suggest that once we come up with a clean directory layout, we will require *every* workflow as well as the regression testing system to produce exactly such a directory structure. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#631 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALLVRYVM4PZZZDDQOPLIYEDTR6BVTANCNFSM46MIKFQQ> .

-- Dr. Shrinivas Moorthi Research Meteorologist Modeling and Data Assimilation Branch Environmental Modeling Center / National Centers for Environmental Prediction 5830 University Research Court - (W/NP23), College Park MD 20740 USA Tel: (301)683-3718 e-mail: ***@***.*** Phone: (301) 683-3718 Fax: (301) 683-3718

[WalterKolczynski-NOAA]

Dom, It is not hard coded; you can always link in your script which is what I do. By the way, in my own scripts I have different directories for different component history and restart files, which also take advantage of links.. Moorthi

Saying you can link files to where you want them is not the same as them not being hardcoded and actually moving the files. Even if every single file in the run directory is soft-linked elsewhere, that doesn't actually clean up the run directory; you just have a big pile of links.

[SMoorthi-emc]

You don't want to hard code files (or directories) in the model code. Actually, you should not even have to look at the run directory unless the model crashes. All the important output should go elsewhere.

…

On Wed, Jun 9, 2021 at 12:35 PM Walter Kolczynski - NOAA < ***@***.***> wrote: Dom, It is not hard coded; you can always link in your script which is what I do. By the way, in my own scripts I have different directories for different component history and restart files, which also take advantage of links.. Moorthi Saying you can link files to where you want them is not the same as them not being hardcoded and actually moving the files. Even if every single file in the run directory is soft-linked elsewhere, that doesn't actually clean up the run directory; you just have a big pile of links. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#631 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALLVRYVTT3IWTEAL4HURPLDTR6J53ANCNFSM46MIKFQQ> .

-- Dr. Shrinivas Moorthi Research Meteorologist Modeling and Data Assimilation Branch Environmental Modeling Center / National Centers for Environmental Prediction 5830 University Research Court - (W/NP23), College Park MD 20740 USA Tel: (301)683-3718 e-mail: ***@***.*** Phone: (301) 683-3718 Fax: (301) 683-3718

[climbfuji]

I agree with Walter. Also, run directories should be entirely self contained in their nature. By default, all input and output should be in the directory, same as the job_card, the error logs, .... If someone sets links to write output elsewhere, that's the user's own decision But the model has to think it is writing into the run directory.

…

On Jun 9, 2021, at 10:35 AM, Walter Kolczynski - NOAA ***@***.***> wrote: Dom, It is not hard coded; you can always link in your script which is what I do. By the way, in my own scripts I have different directories for different component history and restart files, which also take advantage of links.. Moorthi Saying you can link files to where you want them is not the same as them not being hardcoded and actually moving the files. Even if every single file in the run directory is soft-linked elsewhere, that doesn't actually clean up the run directory; you just have a big pile of links. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#631 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5C2RIYCMOJ3LC5HKGPGMLTR6J5ZANCNFSM46MIKFQQ>.

[yangfanglin]

Please do not change the structure too much. GFSv16 directory structure was set up with consultation with NCO and with the expectation that it will be used for future coupled models. Please discuss with NCO if you are making significant changes. If possible please keep INPUT and RESTART directories as clean as possible. There are too many extra unused and redundant files saved in the INPUT directory in the regression and coupled model samples. Fanglin

…

On Wed, Jun 9, 2021 at 12:10 PM Walter Kolczynski - NOAA < ***@***.***> wrote: If input files are also a big concern, one solution would be for each component to have its own directory with input, output, and restart directories. I agree this is probably going to have to reach down into the individual components. Likely straightforward once a target structure is determined, but tedious and requiring coordination. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#631 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKY5N2K5JXKNDB4AJITE7NLTR6G6TANCNFSM46MIKFQQ> .

-- *Fanglin Yang, Ph.D.* *Chief, Model Physics Group* *Modeling and Data Assimilation Branch* *NOAA/NWS/NCEP Environmental Modeling Center* *https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/ <https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/>*

[SMoorthi-emc]

Well, that is not the way operational GFS does. On Wed, Jun 9, 2021 at 12:42 PM Dom Heinzeller ***@***.***> wrote:

…

I agree with Walter. Also, run directories should be entirely self contained in their nature. By default, all input and output should be in the directory, same as the job_card, the error logs, .... If someone sets links to write output elsewhere, that's the user's own decision But the model has to think it is writing into the run directory. > On Jun 9, 2021, at 10:35 AM, Walter Kolczynski - NOAA ***@***.***> wrote: > > > Dom, It is not hard coded; you can always link in your script which is what I do. By the way, in my own scripts I have different directories for different component history and restart files, which also take advantage of links.. Moorthi > > Saying you can link files to where you want them is not the same as them not being hardcoded and actually moving the files. Even if every single file in the run directory is soft-linked elsewhere, that doesn't actually clean up the run directory; you just have a big pile of links. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub < #631 (comment)>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AB5C2RIYCMOJ3LC5HKGPGMLTR6J5ZANCNFSM46MIKFQQ >. > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#631 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALLVRYV7IKMJ7TYSBIM5OEDTR6KVNANCNFSM46MIKFQQ> .

-- Dr. Shrinivas Moorthi Research Meteorologist Modeling and Data Assimilation Branch Environmental Modeling Center / National Centers for Environmental Prediction 5830 University Research Court - (W/NP23), College Park MD 20740 USA Tel: (301)683-3718 e-mail: ***@***.*** Phone: (301) 683-3718 Fax: (301) 683-3718

[climbfuji]

I would suggest to have a meeting between the code managers, workflow developers, and stakeholders (NCO) to determine what a "good" directory structure is. The advantage of having something self-contained is that one can simply pass it on to another person / copy it to another machine. This greatly facilitates collaborating and debugging.

…

On Jun 9, 2021, at 10:49 AM, SMoorthi-emc ***@***.***> wrote: Well, that is not the way operational GFS does. On Wed, Jun 9, 2021 at 12:42 PM Dom Heinzeller ***@***.***> wrote: > I agree with Walter. Also, run directories should be entirely self > contained in their nature. By default, all input and output should be in > the directory, same as the job_card, the error logs, .... > > If someone sets links to write output elsewhere, that's the user's own > decision But the model has to think it is writing into the run directory. > > > On Jun 9, 2021, at 10:35 AM, Walter Kolczynski - NOAA ***@***.***> wrote: > > > > > > Dom, It is not hard coded; you can always link in your script which is > what I do. By the way, in my own scripts I have different directories for > different component history and restart files, which also take advantage of > links.. Moorthi > > > > Saying you can link files to where you want them is not the same as them > not being hardcoded and actually moving the files. Even if every single > file in the run directory is soft-linked elsewhere, that doesn't actually > clean up the run directory; you just have a big pile of links. > > > > — > > You are receiving this because you commented. > > Reply to this email directly, view it on GitHub < > #631 (comment)>, > or unsubscribe < > https://github.com/notifications/unsubscribe-auth/AB5C2RIYCMOJ3LC5HKGPGMLTR6J5ZANCNFSM46MIKFQQ > >. > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#631 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ALLVRYV7IKMJ7TYSBIM5OEDTR6KVNANCNFSM46MIKFQQ> > . > -- Dr. Shrinivas Moorthi Research Meteorologist Modeling and Data Assimilation Branch Environmental Modeling Center / National Centers for Environmental Prediction 5830 University Research Court - (W/NP23), College Park MD 20740 USA Tel: (301)683-3718 e-mail: ***@***.*** Phone: (301) 683-3718 Fax: (301) 683-3718 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#631 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5C2RJOHXEM4E56RJUTMRDTR6LSXANCNFSM46MIKFQQ>.

[SMoorthi-emc]

Here is an example of my output directory with coupled GFS/MOM6/CICE on wcoss "/gpfs/dell2/ptmp/Shrinivas.Moorthi/CFV3/2013010100/c384_phyaf/gfs.20130101/00" contains "ATM_RESTART gfs.t00z.logf015.nc gfs.t00z.master.grb2f033 gfs.t00z.sfluxgrbf000.grib2 gfs.t00z.atmf000.nc gfs.t00z.logf018.nc gfs.t00z.master.grb2f036 gfs.t00z.sfluxgrbf003.grib2 gfs.t00z.atmf003.nc gfs.t00z.logf021.nc gfs.t00z.master.grb2f039 gfs.t00z.sfluxgrbf006.grib2 gfs.t00z.atmf006.nc gfs.t00z.logf024.nc gfs.t00z.master.grb2f042 gfs.t00z.sfluxgrbf009.grib2 gfs.t00z.atmf009.nc gfs.t00z.logf027.nc gfs.t00z.master.grb2f045 gfs.t00z.sfluxgrbf012.grib2 gfs.t00z.atmf012.nc gfs.t00z.logf030.nc gfs.t00z.master.grb2f048 gfs.t00z.sfluxgrbf015.grib2 gfs.t00z.atmf015.nc gfs.t00z.logf033.nc gfs.t00z.sfcf000.nc gfs.t00z.sfluxgrbf018.grib2 gfs.t00z.atmf018.nc gfs.t00z.logf036.nc gfs.t00z.sfcf003.nc gfs.t00z.sfluxgrbf021.grib2 gfs.t00z.atmf021.nc gfs.t00z.logf039.nc gfs.t00z.sfcf006.nc gfs.t00z.sfluxgrbf024.grib2 gfs.t00z.atmf024.nc gfs.t00z.logf042.nc gfs.t00z.sfcf009.nc gfs.t00z.sfluxgrbf027.grib2 gfs.t00z.atmf027.nc gfs.t00z.logf045.nc gfs.t00z.sfcf012.nc gfs.t00z.sfluxgrbf030.grib2 gfs.t00z.atmf030.nc gfs.t00z.logf048.nc gfs.t00z.sfcf015.nc gfs.t00z.sfluxgrbf033.grib2 gfs.t00z.atmf033.nc gfs.t00z.master.grb2f000 gfs.t00z.sfcf018.nc gfs.t00z.sfluxgrbf036.grib2 gfs.t00z.atmf036.nc gfs.t00z.master.grb2f003 gfs.t00z.sfcf021.nc gfs.t00z.sfluxgrbf039.grib2 gfs.t00z.atmf039.nc gfs.t00z.master.grb2f006 gfs.t00z.sfcf024.nc gfs.t00z.sfluxgrbf042.grib2 gfs.t00z.atmf042.nc gfs.t00z.master.grb2f009 gfs.t00z.sfcf027.nc gfs.t00z.sfluxgrbf045.grib2 gfs.t00z.atmf045.nc gfs.t00z.master.grb2f012 gfs.t00z.sfcf030.nc gfs.t00z.sfluxgrbf048.grib2 gfs.t00z.atmf048.nc gfs.t00z.master.grb2f015 gfs.t00z.sfcf033.nc ICE_HISTORY gfs.t00z.logf000.nc gfs.t00z.master.grb2f018 gfs.t00z.sfcf036.nc ICE_RESTART gfs.t00z.logf003.nc gfs.t00z.master.grb2f021 gfs.t00z.sfcf039.nc INPUT gfs.t00z.logf006.nc gfs.t00z.master.grb2f024 gfs.t00z.sfcf042.nc MED_RESTART gfs.t00z.logf009.nc gfs.t00z.master.grb2f027 gfs.t00z.sfcf045.nc OCN_HISTORY gfs.t00z.logf012.nc gfs.t00z.master.grb2f030 gfs.t00z.sfcf048.nc OCN_RESTART" I could have made a separate direcory for ATM history, but did not want to change the way GFS does. On Wed, Jun 9, 2021 at 12:48 PM Fanglin Yang ***@***.***> wrote:

…

Please do not change the structure too much. GFSv16 directory structure was set up with consultation with NCO and with the expectation that it will be used for future coupled models. Please discuss with NCO if you are making significant changes. If possible please keep INPUT and RESTART directories as clean as possible. There are too many extra unused and redundant files saved in the INPUT directory in the regression and coupled model samples. Fanglin On Wed, Jun 9, 2021 at 12:10 PM Walter Kolczynski - NOAA < ***@***.***> wrote: > If input files are also a big concern, one solution would be for each > component to have its own directory with input, output, and restart > directories. > > I agree this is probably going to have to reach down into the individual > components. Likely straightforward once a target structure is determined, > but tedious and requiring coordination. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > < #631 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AKY5N2K5JXKNDB4AJITE7NLTR6G6TANCNFSM46MIKFQQ > > . > -- *Fanglin Yang, Ph.D.* *Chief, Model Physics Group* *Modeling and Data Assimilation Branch* *NOAA/NWS/NCEP Environmental Modeling Center* *https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/ <https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/>* — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#631 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALLVRYWXDGXOIXRNIJXSQSDTR6LPJANCNFSM46MIKFQQ> .

-- Dr. Shrinivas Moorthi Research Meteorologist Modeling and Data Assimilation Branch Environmental Modeling Center / National Centers for Environmental Prediction 5830 University Research Court - (W/NP23), College Park MD 20740 USA Tel: (301)683-3718 e-mail: ***@***.*** Phone: (301) 683-3718 Fax: (301) 683-3718

[DeniseWorthen]

I agree w/ Dom's comment. Even this small sampling of comments indicate that what you want/need depends entirely on where you sit. From the perspective of a code manager, having to travel across multiple parallel subdirectories ("you should not even have to look at the run directory") is 100% opposite of my needs. I want everything self-contained because looking at the run directory is exactly what I need to do.

[JessicaMeixner-NOAA]

@junwang-noaa for v16, the wave restart files are written to: $RUNDIR/restart_wave and in the develop branch WW3 just writes its restarts to $RUNDIR.

[SMoorthi-emc]

This is good for regression tests but not for operations or seasonal prediction or multi year integration .

…

On Wed, Jun 9, 2021 at 12:56 PM Denise Worthen ***@***.***> wrote: I agree. Even this small sampling of comments indicate that what you want/need depends entirely on where you sit. From the perspective of a code manager, having to travel across multiple parallel subdirectories ("you should not even have to look at the run directory") is 100% opposite of my needs. I want everything self-contained because looking at the run directory is exactly what I need to do. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#631 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALLVRYW56NFOSMFIW7UC7OTTR6MKLANCNFSM46MIKFQQ> .

-- Dr. Shrinivas Moorthi Research Meteorologist Modeling and Data Assimilation Branch Environmental Modeling Center / National Centers for Environmental Prediction 5830 University Research Court - (W/NP23), College Park MD 20740 USA Tel: (301)683-3718 e-mail: ***@***.*** Phone: (301) 683-3718 Fax: (301) 683-3718

[climbfuji]

Let me note that the regional workflow implemented two different "modes" that set up different directory structures: a "develop mode" (research, debugging, development) and an "nco" mode (for operations). Not saying we need to go down this route, but it is an idea worth considering.

…

On Jun 9, 2021, at 11:00 AM, SMoorthi-emc ***@***.***> wrote: This is good for regression tests but not for operations or seasonal prediction or multi year integration . On Wed, Jun 9, 2021 at 12:56 PM Denise Worthen ***@***.***> wrote: > I agree. Even this small sampling of comments indicate that what you > want/need depends entirely on where you sit. From the perspective of a code > manager, having to travel across multiple parallel subdirectories ("you > should not even have to look at the run directory") is 100% opposite of my > needs. I want everything self-contained because looking at the run > directory is exactly what I need to do. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#631 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ALLVRYW56NFOSMFIW7UC7OTTR6MKLANCNFSM46MIKFQQ> > . > -- Dr. Shrinivas Moorthi Research Meteorologist Modeling and Data Assimilation Branch Environmental Modeling Center / National Centers for Environmental Prediction 5830 University Research Court - (W/NP23), College Park MD 20740 USA Tel: (301)683-3718 e-mail: ***@***.*** Phone: (301) 683-3718 Fax: (301) 683-3718 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#631 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5C2RM4CMO5HH5TASNSROLTR6M3FANCNFSM46MIKFQQ>.

[junwang-noaa]

I think we need first to figure out which model components can do structured input/output files through namelist and which components need actual source code change. Since many UFS components are shared by many applications, the code structure change for those components requiring code changes may impact a broad community, e.g. if we need to add code change to MOM6 to have the structured input/output, then all the applications using MOM6 need to make corresponding changes in their workflow.

…

On Wed, Jun 9, 2021 at 12:56 PM Jessica Meixner ***@***.***> wrote: @junwang-noaa <https://github.com/junwang-noaa> for v16, the wave restart files are written to: $RUNDIR/restart_wave and in the develop branch WW3 just writes its restarts to $RUNDIR. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#631 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI7D6TIGI7WECC2XQUYERLLTR6MLVANCNFSM46MIKFQQ> .

[SMoorthi-emc]

I don't think you need to change code. It is all in the scripts.

…

On Wed, Jun 9, 2021 at 1:06 PM Jun Wang ***@***.***> wrote: I think we need first to figure out which model components can do structured input/output files through namelist and which components need actual source code change. Since many UFS components are shared by many applications, the code structure change for those components requiring code changes may impact a broad community, e.g. if we need to add code change to MOM6 to have the structured input/output, then all the applications using MOM6 need to make corresponding changes in their workflow. On Wed, Jun 9, 2021 at 12:56 PM Jessica Meixner ***@***.***> wrote: > @junwang-noaa <https://github.com/junwang-noaa> for v16, the wave restart > files are written to: $RUNDIR/restart_wave and in the develop branch WW3 > just writes its restarts to $RUNDIR. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > < #631 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AI7D6TIGI7WECC2XQUYERLLTR6MLVANCNFSM46MIKFQQ > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#631 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALLVRYRBAU7Q6ZOQ3XGJQGTTR6NPPANCNFSM46MIKFQQ> .

-- Dr. Shrinivas Moorthi Research Meteorologist Modeling and Data Assimilation Branch Environmental Modeling Center / National Centers for Environmental Prediction 5830 University Research Court - (W/NP23), College Park MD 20740 USA Tel: (301)683-3718 e-mail: ***@***.*** Phone: (301) 683-3718 Fax: (301) 683-3718

[yangfanglin]

for FV3, INPUT and RESTART are defined in the code On Wed, Jun 9, 2021 at 1:10 PM SMoorthi-emc ***@***.***> wrote:

…

I don't think you need to change code. It is all in the scripts. On Wed, Jun 9, 2021 at 1:06 PM Jun Wang ***@***.***> wrote: > I think we need first to figure out which model components can do > structured input/output files through namelist and which components need > actual source code change. Since many UFS components are shared by many > applications, the code structure change for those components requiring code > changes may impact a broad community, e.g. if we need to add code change to > MOM6 to have the structured input/output, then all the applications using > MOM6 need to make corresponding changes in their workflow. > > On Wed, Jun 9, 2021 at 12:56 PM Jessica Meixner ***@***.***> > wrote: > > > @junwang-noaa <https://github.com/junwang-noaa> for v16, the wave > restart > > files are written to: $RUNDIR/restart_wave and in the develop branch WW3 > > just writes its restarts to $RUNDIR. > > > > — > > You are receiving this because you were mentioned. > > Reply to this email directly, view it on GitHub > > < > #631 (comment) > >, > > or unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/AI7D6TIGI7WECC2XQUYERLLTR6MLVANCNFSM46MIKFQQ > > > > . > > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > < #631 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/ALLVRYRBAU7Q6ZOQ3XGJQGTTR6NPPANCNFSM46MIKFQQ > > . > -- Dr. Shrinivas Moorthi Research Meteorologist Modeling and Data Assimilation Branch Environmental Modeling Center / National Centers for Environmental Prediction 5830 University Research Court - (W/NP23), College Park MD 20740 USA Tel: (301)683-3718 e-mail: ***@***.*** Phone: (301) 683-3718 Fax: (301) 683-3718 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#631 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKY5N2JJJT4XVSPBAOB2ERLTR6N7VANCNFSM46MIKFQQ> .

-- *Fanglin Yang, Ph.D.* *Chief, Model Physics Group* *Modeling and Data Assimilation Branch* *NOAA/NWS/NCEP Environmental Modeling Center* *https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/ <https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/>*

[WalterKolczynski-NOAA]

I think we need to cut through some of the static here. Any linking or any structure outside of the run directory is besides the point for this conversation. COM or ROTDIR or whatever can still be structured however it is desired. This is just about organizing the working directory.

[WalterKolczynski-NOAA]

Let me note that the regional workflow implemented two different "modes" that set up different directory structures: a "develop mode" (research, debugging, development) and an "nco" mode (for operations). Not saying we need to go down this route, but it is an idea worth considering.
…

We need to stop doing this as much as possible. It's a headache to maintain and just introduces more errors.

[jiandewang]

For MOM, input are stored at INPUT dir, restart are stored at RESTART dir, output are in run dir which is controlled by FMS. I will do some offline test to see if we can let output being stored in a specified dir.

[DeniseWorthen]

This issue has been moved the ufs-weather-model discussions.

[laurenfrederick]

@junwang-noaa Is this discussion still valid or should it be closed out?