Minor improvement in ESMX data component

[uturuncoglu]

This PR aims to improve ESMX data component by adding additional options for ESMF_FieldFill calls.

I initially testing with following configuration:

ATM:
  model: ESMX_Data
  petList: 0-1
  geom:
    nx: 360
    ny: 180
    coordSys: ESMF_COORDSYS_SPH_DEG
    minx: 0.0
    maxx: 360.0
    miny: -90.0
    maxy: 90.0
  exportFields:
    sea_surface_temperature: {dim: 2, scheme: "sincos", member: 10, step: 1, val: 273}
  attributes:
    Verbosity: low
    Diagnostic: 0

The implementation does not checking exiting behavior and it is backward compatibility but user could add additional arguments to import and/or export states like scheme , member and also step.

the given configuration is creating global data like following,

[uturuncoglu]

@danrosen25 The sincos is creating more spatial diverse field (ranges -1, 1) but I am not sure we would like to alter its range by adding the value given by val argument. I think it would be nice to have it then you could have both spatial changes in addition to given value of the field. So, if you set val to 273 then it would range 272-274 which would be more realistic. Also, I am not sure how step argument is working on FieldFill. Maybe with constant option etc. it is activated.

[danrosen25]

There's actually no change to TransferOfferGeomObject as "will provide" is the default. So this change can be omitted. For the field fill change I suggest omitting the member and step options as they are confusing. Instead add a value range. The range is computed as (((max - min) / 2) * sincos_value) + ((max + min) / 2). This will allow for a real value range to be exported from ESMX_Data, which is the intention of this component. Also, I think that scheme should be re-labed as fill_scheme or fill_type or filtyp or something like that. It should also accept constant as an option and not just const

[uturuncoglu]

@danrosen25 Thanks for your help. I agree, let me remove TransferOfferGeomObject change but I think at least member needs to be in there since it changes the behavior of the spatial pattern. The default value is 1 for it and it is creating a field that looks one value for each quarter of sphere. So, increasing member size makes look as the one in example. I can add value range in addition to the member. step does not do anything at least as I see. Lat me know what you think.

[danrosen25]

@danrosen25 Thanks for your help. I agree, let me remove TransferOfferGeomObject change but I think at least member needs to be in there since it changes the behavior of the spatial pattern. The default value is 1 for it and it is creating a field that looks one value for each quarter of sphere. So, increasing member size makes look as the one in example. I can add value range in addition to the member. step does not do anything at least as I see. Lat me know what you think.

By adding the value range for sincos you won't need member or step.

[uturuncoglu]

@danrosen25 But then we will loose resolution of spatial variability. It is basically, increased with the size of the member. Anyway, let me experiment it.

[uturuncoglu]

@danrosen25 Okay. Here are the changes,

• Removed transfer option
• I implemented your way to set range for the fields. I also did it for import fields but maybe I need to remove that one since it seems you are using max and min for testing. Let me know if you want me to remove it.

So, following works fine for me,

    sea_surface_temperature: {dim: 2, scheme: "sincos", member: 10, min: 275.0, max: 285.0}
    eastward_wind_at_10m_height: {dim: 2, scheme: "sincos", member: 5, min: -5.0, max: 5.0}
    northward_wind_at_10m_height: {dim: 2, scheme: "sincos", member: 5, min: -2.0, max: 2.0}

again, I kept member option since the value of the member is controlling the spatial distribution of the variable.

One more thing that we could add the temporal variation. We could modify the value of the data based on the time but not sure about best way to do it. Maybe we could skip that one for now and implement in the future.

I am also plaining to update ESMX_Data README file to include more information about new supported options.

[danrosen25]

Better but I still think there can be better descriptors for the scheme and member configuration options. If I said In a sentence "set the scheme for sea_surface_temperature" or "set the member for sea_surface_temperature" neither or these would describe what you're doing. 'fill_scheme' and 'fill_offset' describe the configuration options better I'm not set on these either. Maybe @theurich @billsacks have some ideas for configuration options for the fill scheme and sincos member user facing configuration options.

[uturuncoglu]

@danrosen25 Thanks for your help and willing to review. Sure, I could change those argument names. fill_scheme looks good but I think fill_offset is not the one that we are looking for. I think that the member found in FieldFill is the number of waves generated by the sincos function. Maybe @oehmke might have better idea for the argument name. Once, we have consensus about it I could change them easily.

[danrosen25]

@uturuncoglu @oehmke Here's how member is used to modify the sincos fill scheme.

              do i=lbound(dataPtrR4D2,1),ubound(dataPtrR4D2,1)
                dataPtrR4D2(i,j) = real( &
                  cos(real(l_member)*3.1416*(coord1PtrR8D1(i)+real(l_step))/360.)&
                  * &
                  sin(real(l_member)*3.1416*(coord2PtrR8D1(j)+real(l_step))/90.)&
                  , ESMF_KIND_R4)
              enddo

[anntsay]

Core team discussion: change "member" to "modifier" and pre-fix "fill_"

[anntsay]

@uturuncoglu and @theurich to coordinate on the PRs in this area.