Floating point lists for NUOPC_CompAttributeGet

[NickSzapiro-NOAA]

Requirements

• Reviewed NUOPC Reference Manual
• Searched GitHub Discussions

Affiliation(s)

Lynker in support of NCEP EMC

ESMF Version

v8.6.1

Issue

Hi. In short, I have floating point ALLCOMP attributes in a UFS configure file. Is it possible to add support for list of floating point to NUOPC_CompAttributeGet?

I see that

• ESMF attributes support list of integer, real, double precision, logical, or character values
• NUOPC_CompAttributeGet is more limited to list of integer and string

If not, I then need some intermediate conversion string-->double. Some current implementations of this are not robust across compiler options.

Alternately, I don't know if there is some way to call something like ESMF_InfoGetAlloc but with a differently formatted UFS configure file... Any guidance/feedback is appreciated.

Autotag

@danrosen25

[danrosen25]

Hi @NickSzapiro-NOAA
We can add this to our backlog. Do you have a sense of the urgency?
I've created an issue here
In the meantime this can be accomplished in user code using
call ESMF_InfoGet(info, key="/NUOPC/Instance/"//name, values=valueList, rc=rc)
but you'll want to add checks similar to how it's done in NUOPC for getting an integer list.

esmf/src/addon/NUOPC/src/NUOPC_Comp.F90

Line 1324 in edb848d

subroutine NUOPC_GridCompAttributeGetIL(comp, name, valueList, isPresent, &

[NickSzapiro-NOAA]

Thanks for the solution @danrosen25! I missed the "/NUOPC/Instance/" part for key and got stuck.
I don't think this is urgent as we could edit implementation when available. It would be nice to have though, as there will be similar code in several components

[NickSzapiro-NOAA]

It looks like ESMF_InfoGetAlloc is misunderstanding the attribute type as string rather than number.

20240906 175245.904 ERROR            PET34 /scratch1/NCEPDEV/nems/role.epic/spack-stack/spack-stack-1.6.0/cache/build_stage/spack-stage-esmf-8.6.0-nnuwc5zlpvogeiuk3nec26eryjiwsopw/spack-src/src/Infrastructure/Base/src/ESMCI_Info.C:820 Info::get(): Failed type check (JSON trace will follow): /NUOPC/Instance/restart_fh
20240906 175245.904 ERROR            PET34 ESMCI_Info.C:822 Info::get() Attribute incorrect typekind  - [json.exception.type_error.302] type must be number, but is string
20240906 175245.904 ERROR            PET34 ESMCI_Info.C:836 Info::get() Attribute incorrect typekind  - Internal subroutine call returned Error
20240906 175245.904 ERROR            PET34 ESMC_InfoCDefGeneric.C:210 ESMC_InfoGetArrayR8() Attribute incorrect typekind  - Internal subroutine call returned Error
20240906 175245.904 ERROR            PET34 ESMF_Info.F90:1424 ESMF_InfoGetArrayR8Alloc() Attribute incorrect typekind  - Internal subroutine call returned Error
20240906 175245.904 ERROR            PET34 ice_comp_nuopc.F90:540 Attribute incorrect typekind  - Passing error in return code
20240906 175245.904 ERROR            PET34 UFS Driver Grid Comp:src/addon/NUOPC/src/NUOPC_Driver.F90:2901 Attribute incorrect typekind  - Phase 'IPDv01p1' Initialize for modelComp 4: ICE did not return ESMF_SUCCESS
20240906 175245.904 ERROR            PET34 UFS Driver Grid Comp:src/addon/NUOPC/src/NUOPC_Driver.F90:1324 Attribute incorrect typekind  - Passing error in return code
20240906 175245.904 ERROR            PET34 UFS Driver Grid Comp:src/addon/NUOPC/src/NUOPC_Driver.F90:486 Attribute incorrect typekind  - Passing error in return code
20240906 175245.904 ERROR            PET34 UFS.F90:394 Attribute incorrect typekind  - Aborting UFS

Can I set this somehow? I want array of type real(kind=ESMF_KIND_R8)

[danrosen25]

How are you setting the attribute / what does your configuration file look like for restart_fh? If you're using the slightly outdated ESMF_Config class then you should convert each item in a string list into real using function num = ESMF_UtilString2Real(string, rc). I think the ESMF_Config class treats all input as a string. If you're using the ESMF_HConfig class (YAML) then remove any quotations from the restart_fh value.

[NickSzapiro-NOAA]

The idea is for user to be able to input something in UFS configure file like
https://github.com/NickSzapiro-NOAA/ufs-weather-model/blob/restart_fh_marine/tests/parm/ufs.configure.datm_cdeps.IN#L123

ALLCOMP_attributes::
...
      restart_n = 12
      restart_option = nhours
      restart_ymd = -999
      write_restart_at_endofrun = .true.
      restart_fh = 0.05,0.25,0.5,3,6
 ...
 ::

This keeps options together for components to write restarts. Can change delimiter/whitespace requirements, if it helps.

May I check that I understand? For a solution across ESMF versions and classes, input user's restart_fh as list of strings and call UtilString2Real on each?

In first testing, input shows up as one string with commas instead of array of strings. To split long string, subroutine decodeName looks great but not public

[danrosen25]

Hi @NickSzapiro-NOAA @theurich
From what I can tell ESMF_Config -> ESMF_Info -> NUOPC Attributes isn't working correctly. There has been a focus on ESMF_HConfig -> ESMF_Info -> NUOPC Attributes recently, which might be why this has been missed.
What's broken

<COMP>_attributes::
      restart_fh = 0.05,0.25,0.5,3,6
 ::

Lists aren't working. This is seen as a single string.

<COMP>_attributes::
      restart_fh = 0.05, 0.25, 0.5, 3, 6
 ::

Spaces are breaking ESMF_Info. So NUOPC attributes doesn't store restart_fhat all. This is also true for restart_fh = "0.05, 0.25, 0.5, 3, 6".

[danrosen25]

I've created a second issue for this bug here
After some research I determined that NUOPC_CompAttributeIngest (called in the UFS driver to add attribute information to a component) fails silently if there are more than one item on the right hand side of the configuration line.

[NickSzapiro-NOAA]

@danrosen25 Maybe more fundamentally, may we ask if it would be possible for ESMF/NUOPC code to provide an
is_restart_time?-->true/false function with model time input for all components to share?

We would want a slight tweak to restart_fh attribute above, where if second number is -1 then first number is interpreted as a frequency rather than specific forecast hour. This "encoding" is as in FV3 output_fh (NOAA-EMC/fv3atm#345)

[junwang-noaa]

@danrosen25 This is actually a more general question on ESMF clock. Right now ESMF clock provides info such as start time, current time, time step, etc. I am wondering if the clock can also provide restart time (which by nature applies to all the sub components) if a restart time info is provided in the top configuration file in ESMX. Once we set the restart time in the main driver, the restart time can be passed down to the subcomponents and an ESMF call (e.g. ESMF_isRestartTime) can be accessed from those sub components. Currently we have to implement the restart info in every model components, which in my mind is not a clean solution.

[danrosen25]

@junwang-noaa What does it currently look like?
I think you're asking about attaching an alarm to the driver clock. The driver clock is accessible from every NUOPC component. But I'm not sure if this is the solution you need. Are you asking to pass a time interval to every model and use that time interval to write restart files?

[junwang-noaa]

It is not actually alarm. Just like we can get currtime with starttime and time step/time interval, I'd like to see if ESMF can provide restarttime from ESMF clock. There is a limitation on using alarm as it has to be repeated in a fixed frequency. We actually would like to know the restart time and compare it directly with currtime without using alarm.

[danrosen25]

Hi @junwang-noaa,
I'll discuss this with the ESMF team on our core call. Thanks!

[danrosen25]

@junwang-noaa @NickSzapiro-NOAA @anntsay
The ESMF Core team did some brainstorming and we have a resolution. Ann is going reach out to set up a planning discussion.