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)

[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.

[anntsay]

Meeting note: 10/30:

Jun: trying to get restart time.. had to implement the configuration code in every component.. so hoping to have a flexible restart time = a variable to integrate in the clock to help trigger restart/writing time. current workaround, every component has a restart. ->

Nick: current workaround implementation: https://github.com/NickSzapiro-NOAA/ufs-weather-model/blob/restart_fh_marine/CDEPS-interface/ufs/cdeps_share/shr_is_restart_fh_mod.F90

Dan: clock cannot contain a clock and but can have an alarm. maybe have an alarm.

Jun: for example, restart every 12 hours.. so the component can check alarm and to trigger restart. could have several alarms to mitigate different frequency of triggering.. but code is messy

Bill: possible to extend the current alarm capabilities.

Jun: question about alarm: subcomponent only inherit from parent component.. but somehow cannot see alarm passing down to subcomponent. the original question is whether the restart time or alarm can be passed down to subcomponent
Dan-> can attach the alarm to the clock and has to manually done in the driver.
Gerhard -> fetchclock and set run clock -> set during run phase (in NUOPC document)
Jun: the problem is that the alarm is a frequency

Next Step:

1. UFS team is working Nick's current workaround
2. another potential work around (Gerhard/Dan) - (1) Leverage reference time in the clock. in Parent clock (driven by run sequence), could have the driver in charge, and has a list of time in a configuration file. the driver register in the run sequence, and check current time and then look at the list of restart time and fetch that as a reference time. can now the child to look up the reference time. (2) use alarm
3. targeting 8.8 release -> trying to fix how the all_comp is working.
4. in future releases -> ESFM team will consider this feature request and work into clock/alarm class