CICE-Consortium / CICE

Development repository for the CICE sea-ice model
Other
60 stars 132 forks source link

dsnow optional argument in icepack_step_therm1 #908

Open apcraig opened 1 year ago

apcraig commented 1 year ago

There seems to be a complication with the "dsnow" optional argument in icepack_step_therm1. This shows up in the output from most compilers as something like

>diff ../derecho_intel_smoke_gx3_8x2_diag1_run5day.tre03d/logs/cice.runlog.231115-172605 ../derecho_intel_unittest_gx3_8x2_cmplog_diag1_opticep_run5day.tre03d/logs/cice.runlog.231115-184013 | more
1031c1029
< snow change (m)        =       -0.00000237267541165       0.00000274654110168
---
> snow change (m)        =        0.00000000000000000       0.00000000000000000

I think the problem is created because dsnown is NOT optional and is computed in icepack. dsnow is initialized to 0 in cice but if it's passed, then dsnow is computed/updated in merge_fluxes from dsnown. This does not seem to change answers, I guess because dsnown is an active variable and dsnow is just a diagnostic? Should dsnow be required to be passed in icepack_step_therm1? Should we get rid of the diagnostic output in CICE? Should we just treat this as OK?

dabail10 commented 4 months ago

Finally getting back to this one. I think we want dsnow to be non-optional. This looks like a diagnostic that is on regardless of the configuration. There is a history variable f_dsnow that is not on by default.

eclare108213 commented 4 months ago

I agree, if dsnown is not optional and the diagnostic dsnow is always printed, then make dsnow non-optional. The other option would be to get rid of the diagnostic output (or wrap it in an if statement of some kind), but I think it's useful to consistently have it in the diagnostic output.