Purpose

So we have been running into issues with the Hector best fits for a single ESM because think that diff and S are unidentifiable when we are only using temperature output as the comparison data, this is what cause optim to return physically unreasonable Hector parameters. We think that we could use the ocean heat flux as another constraint to resolve this issue.

How different is the CMIP5 ocean componet heat flux vs the one we caluclated via atmospheric output?

Since not all of the models returned values for the heat flux (hfds) we are probably going to have to calculate our own CMIP5 heat flux via the following equation rsds-rsus+rlds-rlus-hfss-hfls but we want to make sure that we are calculating the heat flux correctly in terms of equation (we we using the correct variables) and cdo code. Here I compare the CMIP5 hfds results for MIRCO with the heat flux I got from the atmospheric component for MIRCO-ESM. The reason why I chose MIRCO-ESM rcp26 is because I was able to access all of the data for it.

Well I expected these lines to be some what similar to one another but have a few ideas of what could be going on.

  1. There could be a problem with how we calculate the heat flux (from a variable stand point)
  2. There could be a problem with the cdo implantation of our code (I’ve checked the code a few times and I haven’t caught any bugs yet)
  3. MIROC-ESM reported funky heat flux variables (they are all negative which is not what I would have expected)
  4. We are misunderstanding what the hfds variable actually is

The hfds nc meta data information.

File /pic/projects/GCAM/CMIP5-KDorheim/hfds/hfds_Omon_MIROC-ESM_rcp26_r1i1p1_200601-210012.nc (NC_FORMAT_CLASSIC):

     4 variables (excluding dimension variables):
        double time_bnds[bnds,time]   
        double lat_bnds[bnds,lat]   
        double lon_bnds[bnds,lon]   
        float hfds[lon,lat,time]   
            standard_name: surface_downward_heat_flux_in_sea_water
            long_name: Downward Heat Flux at Sea Water Surface
            comment: "This is the net flux of heat entering the liquid water column through its upper surface (excluding any ""flux adjustment"") ."
            units: W m-2
            original_name: hfds
            original_units: W/m2
            history: 2011-09-13T06:53:50Z altered by CMOR: Converted units from 'W/m2' to 'W m-2'. 2011-09-13T06:53:50Z altered by CMOR: replaced missing value flag (-999) with standard missing value (1e+20).
            cell_methods: time: mean area: mean where sea
            cell_measures: area: areacello
            missing_value: 1.00000002004088e+20
            _FillValue: 1.00000002004088e+20
            associated_files: baseURL: http://cmip-pcmdi.llnl.gov/CMIP5/dataLocation gridspecFile: gridspec_ocean_fx_MIROC-ESM_rcp26_r0i0p0.nc areacello: areacello_fx_MIROC-ESM_rcp26_r0i0p0.nc

How does the noise of the ESM heat flux compare to Hector’s?

If it turns out that there is more noise in the ESM heat flux than the heat flux from the Hector ensemble then we will not be able to use this data as a constraint in the best fit exercise. Here the ESM heat flux data is from CESM1-CAM5 (I calculated from the atmospheric component)

Well it looks like CESM1-CAM5 noise is less than the noise we see from the Hector ensemble! But if we look at only the heat flux from the ESM we see that there are small difference differences between the heat flux from the different experiments compared to the differences in tas or co2 between the different experiments.

Concluding Thoughts

Are we concerned that our ESM heat flux returns very different results those recorded in the hfds file? If not and we think that our Heat Flux calculation is good since the ESM heat flux noise is less than the spread we see in Hector I would like to try using the heat flux data as comparison data in optim. If using the heat flux data leads optim to converge to a solution that uses more physically reasonable Hector parameters I think I would look into downloading more CMIP5 data.