How to handle variables which are not in CMIP6 Tables yet?

[siligam]

@hegish

There are 2 recom variables CO2f and pCO2s which map to variables fgco2 and spco2 respectively in CMIP6 Tables (CMIP6_Omon.json). Also for auto-units conversion support the following code patch was applied

diff --git a/lib/step.rb b/lib/step.rb
index fd5f41e..4f7a2cf 100644
--- a/lib/step.rb
+++ b/lib/step.rb
@@ -214,6 +214,10 @@ module CMORizer
             cmds << CDO_MULC_cmd.new(100)
           when ["K", "degC"]
             cmds << CDO_SUBC_cmd.new(-273.15)
+          when ["mmolC/m2/d", "kg m-2 s-1"]
+            cmds << CDO_MULC_cmd.new(1.390127e-10)
+          when ["uatm", "Pa"]
+            cmd << CDO_MULC_cmd.new(0.101325)
           else
             raise "can not automatically convert unit from '#{from_unit}' to '#{to_unit}'"
           end

seamore match_available produces the following output
# NO match: CO2f 'mmolC/m2/d' day MEAN

Trying cmorize CO2f_day => [fgco2_Omon, fgco2_Oyr] produces the following error

error: uninitialized constant #<Class:#<CMORizer::Project:0x000055d6bcccad38>>::CO2f_day

After setting variable names in the nc files to match the names in the Tables, match_available produces the following output
cmorize fgco2_day => [fgco2_Omon, fgco2_Oyr] # automatically converting unit from 'mmolC/m2/d' to 'kg m-2 s-1’

Question:

• How to properly handle variable names that are not in the table yet?
• Also shown here is a preprocessing step of setting names to aid the tool in recognising the variable name. This sounds as a workaround. Can this workaround be avoided?

Your insights into this problem is very much appreciated.

[mandresm]

Hi @siligam and @hegish,

My understanding of what @siligam and @pgierz found yesterday is that we already know what's the root of the problem:

CO2f is a REcoM variable and it's not included here:

seamore/lib/fesom_possible_var.rb

Lines 43 to 49 in c504b1e

	FESOM_VARIABLE_INITIALIZATION_CODE = <<~'EOFHEREDOC'
	call volo_const%init(1, 'volo', 'total volume of liquid seawater', 'm3') ! this could be optimized, as the value does not change. we use the standard output writer procedure for simplicity
	call soga_mean%init(1, 'soga', 'global average sea water salinity', 'psu')
	call thetaoga_mean%init(1, 'thetaoga', 'global average sea water potential temperature ', 'degC')
	call siarean_mean%init(1, 'siarean', 'total area of sea ice in the Northern hemisphere', '1e6 km2')
	call siareas_mean%init(1, 'siareas', 'total area of sea ice in the Southern hemisphere', '1e6 km2')
	call siextentn_mean%init(1, 'siextentn', 'total area of all Northern-Hemisphere grid cells that are covered by at least 15 % areal fraction of sea ice', '1e6 km2')

@hegish, for me the most important question right now is to understand why finding a possible variable is coded this way (by copy/pasting FORTRAN code from FESOM into fesom_possible_var.rb) and not simply by collecting all variables available in the files matching the file pattern? I'm sure there is a good reason to code it the way you did, however, there is the shortcoming that the variables are harcoded, meaning every time someone decides to create a new variable in FESOM/REcoM source code we would need to add a new line here too.

[siligam]

@mandresm I am closing down this issue as it is address in pull request #8