-
Notifications
You must be signed in to change notification settings - Fork 240
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
Fix RS/RL type in pkg/steep_icecavity #838
Conversation
@owang01 If you could approve this (small) PR quickly I would merge it soon after and I would get some of the daily testreport fixed. Thnaks. |
@owang01 Please ignore my previous comment: I saw that there is also some issues that prevent to compile the isomip adjoint (also with ifort & -devel, even without RS=real*4) so I will try to figure out where the problem is. |
I think I fixed the problems that are making some daily testreport to fail. I also updated this PR description. |
@jm-c Thank you for the extra fixes. The fixes to DIAGNOSTICS_FILL_RS and missing argument NR in calling S/R ADEXCH_3D_RL look good to me (PR descriptions 1 and 2). For the issue related to the local arrays for diagnostic output in |
@owang01 Thanks for the review and the improvement. I am going to merge this PR very soon. |
What changes does this PR introduce?
Fix few issues in recently added (PR #789) package
steep_icecavity
What is the current behaviour?
sticfFreshWaterFlux
andsticfHeatFlux
are declared "_RL" but diagnostics 'SHIICFfw' and 'SHIICFht' are filled by callingDIAGNOSTICS_FILL_RS
(i.e., wrong type).This only matter when "_RS" is "real*4" and fail to compile with strict S/R argument check, e.g, intel compiler & -devel:
http://mitgcm.org/testing/results/2024_05/tr_engaging-ifcMpi_20240525_0/summary.txt
addummy_in_stepping.F
prevents to compile AD exp.isomip
, as seen here:https://mitgcm.org/testing/results/2024_05/tr_svante-ifcAdm_20240526_0/summary.txt
stic_thermodynamics.F
are only initialised whenuseDiagnostics=T
but are used even whenuseDiagnostics=F
; this produce a floating point error when checking for un-initialized vars with open64 compiler and "-devel", as here:https://mitgcm.org/testing/results/2024_05/tr_engaging-o64Adm_20240526_0/summary.txt
What is the new behaviour
Fix all 3.
Does this PR introduce a breaking change?
no
Other information:
Suggested addition to
tag-index
not needed if meged just after PR #789