update namelist and documentation

[eclare108213]

Some namelist parameters changed in Icepack and probably should be made consistent in CICE.

ocn_data_type instead of sst_data_type
bgc_data_type instead of sss_data_type (?)
restore_ocn instead of restore_sst

In Icepack we have all data in data_dir.
Can we do this in CICE, or do we need to keep atm_data_dir, ocn_data_dir, bgc_data_dir?

Add to CICE namelist:

default_season

Same parameter names but different values:

shortwave = 'ccsm3' instead of 'default'
albedo_type = 'ccsm3' instead of 'default'
tfrz_option = 'mushy' instead of 'mushy_layer'

[eclare108213]

We also need to make emmissivity a namelist parameter, see CICE-Consortium/Icepack#211

[apcraig]

Just to add a comment, there is some inconsistency in the shortwave implementation and documentation, and there are differences between icepack and cice. It seems icepack supports ccsm3 and dEdd now. While cice says 'default' and dEdd are the options and 'default' is the actual default in the code. but a shortwave='default' setting in cice leads to a failure in icepack. we should probably get rid of 'default' everywhere or make sure 'default'='ccsm3' as needed.

[eclare108213]

change 'probably' to 'definitely' and yes, I agree

[duvivier]

A few more things (notes for myself):

• Update/clarify some of the testing documentation.
• Check references (need input from Andrew)

[duvivier]

Just an update on my progress and a few questions for @eclare108213 or @apcraig. I will be working on this next week and hopefully get it done early in the week.

These name changes have already been made to the namelist:
sst_data_type --> ocn_data_type
sss_data_type --> bgc_data_type
restore_sst --> restore_ocn

This variable has been added to the namelist:
default_season

Theses namelist value options were changed:
shortwave: default --> ccsm3
albedo_type: default --> ccsm3

These variable was already changed or added to the namelist and don't require any updating:
emissivity
tfrz_option: mushy_layer --> mushy

The main questions remaining are:

1. Should we combine atm_data_dir, ocn_data_dir, and bgc_data_dir to just data_dir? The downside to doing this is that it is more involved since the forcing directories currently specify down all the way from CICE_data/forcing/gx3/NCEP/. Additionally, icepack_in uses atm_data_file, ocn_data_file, bgc_data_file, and ice_data_file to specify each of these forcings. Maybe the equivalent is since we don't specify individual files in cice we should specify individual directories. I'm not really sure what is best here.

2. We just added 'bgc_data_type' to the forcing_nml but we still have sil_data_type, nit_data_type, and fe_data_type in the bgc_nml part of the code. Should we remove these and just use bgc_data_type? Icepack does not specify them, only bgc_data_type.

3. We do not specify bgc_data_format in ice_in but we do in icepack_in. Is this something we need to change?

4. Given the above questions do you want me to go ahead with a PR for the things I have done or should I wait to incorporate the other items? I still need to finish up documentation - as of now I've just done coding.

[duvivier]

I should clarify, the first set of items I list as done, I mean on my development fork I've implemented these changes and I think they are nearly good to go (I will have a few questions on testing).

[eclare108213]

@duvivier in answer to your questions:

1. I would leave these separate rather than combining to data_dir. I was hoping that we could simplify the data directory structure as in Icepack, but you'd have to change the structure on ftp. Let's leave that alone.
2. I don't think we need sil_data_type, etc. We should be able to do this with just bgc_data_type, keeping in mind that what we offer for forcing is only intended for our testing purposes, not science. @njeffery please let us know if you disagree.
3. If the bgc data is all in the same format (I assume this means netcdf vs binary), then we don't need this. I prefer to keep things simple if we can, and if the extra complexity becomes necessary, then it's easy to add namelist variables and still remain backward-compatible.
4. It sounds like you're pretty close to having it done. You can always submit a PR for us to look at while you're working on additional changes, just say in the comments that you're still working on it.

[njeffery]

bgc_data_type is enough. n

…

________________________________ From: Elizabeth Hunke <notifications@github.com> Sent: Friday, October 12, 2018 7:02:30 AM To: CICE-Consortium/CICE Cc: Jeffery, Nicole; Mention Subject: Re: [CICE-Consortium/CICE] update namelist and documentation (#123) @duvivier<https://github.com/duvivier> in answer to your questions: 1. I would leave these separate rather than combining to data_dir. I was hoping that we could simplify the data directory structure as in Icepack, but you'd have to change the structure on ftp. Let's leave that alone. 2. I don't think we need sil_data_type, etc. We should be able to do this with just bgc_data_type, keeping in mind that what we offer for forcing is only intended for our testing purposes, not science. @njeffery<https://github.com/njeffery> please let us know if you disagree. 3. If the bgc data is all in the same format (I assume this means netcdf vs binary), then we don't need this. I prefer to keep things simple if we can, and if the extra complexity becomes necessary, then it's easy to add namelist variables and still remain backward-compatible. 4. It sounds like you're pretty close to having it done. You can always submit a PR for us to look at while you're working on additional changes, just say in the comments that you're still working on it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#123 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AH1K6umkc7VTCDHcjYy_Th0GJQzTwvYLks5ukJLmgaJpZM4TQ3NK>.

[duvivier]

I think that the only outstanding item is to remove sil_data_type, nit_data_type, and fe_data_type and just use bgc_data_type. This will likely require more substantial changes and can be a future enhancement.

[eclare108213]

I have been working on the tracer namelist options (#212) especially for BGC, and will take a look at these. I hope to submit a PR in the next few days.

[apcraig]

Is this done?

[duvivier]

@apcraig I think @eclare108213 is finishing up tracer namelist options (#212) and maybe has submitted a PR. I didn't close it because I think she was doing a bit more, but I have nothing else left that I'm working on.

[eclare108213]

I'm still working on this. Instead of using bgc_data_type for SSS, we need to use it in place of nit_data_type and sil_data_type, and use ocn_data_type for both SST and SSS. This reduces the flexibility of the forcing options in the code, but for testing purposes I think this is okay. I'm leaving fe_data_type in the code for now, since it's fundamentally different from sil and nit.

Do we have forcing data available for SST, SSS 'clim' options? We aren't testing that in CICE, only 'default'. If the mixed layer model is turned on, then we don't need it for SST, but it could still be useful for SSS. I'm inclined to keep things simple and not support 'clim' for SST, SSS.