NOAA-SWPC / WAM

Whole Atmosphere Model extension of the GFS
GNU General Public License v3.0
3 stars 7 forks source link

new works on the Joule Heating factor after new Weimer #8

Closed ZhuxiaoLi66 closed 4 years ago

ZhuxiaoLi66 commented 5 years ago

After the new Weimer plugged in WAM, it seems that we still need to adjust Joule heating factor in idea_ion.f to get it more drivers dependent for storm peak temperature and even for the quiet time.

Tim, Martin, Adam and I are also working on trying to apply pointerflux model of Weimer to constrain the Joule heating calculation in WAM.

ZhuxiaoLi66 commented 5 years ago

monthly_zonal_T_WAM_MSIS_avg_swin_201303l_jdel8_weimer2005_5p monthly_zonal_T_WAM_MSIS_avg_swin_201303_weimer2005_JH_5p_cb

ZhuxiaoLi66 commented 5 years ago

monthly_zonal_T_WAM_MSIS_avg_swin_201503_jdel8_weimer2005_5p_cb monthly_zonal_T_WAM_MSIS_avg_swin_201503_weimer2005_JH_5p_cb monthly_zonal_mean_MMS_WAM_MSIS_2015_weimer2005_JH_5p

akubaryk commented 5 years ago

Tim, Martin, Adam and I are also working on trying to apply pointerflux model of Weimer to constrain the Joule heating calculation in WAM.

In basic terms, this is going to require an area-weighted average of the joule heating factor to come out of the physics routines. I believe this is going to be possible with a one-lagged-timestep global mean of the JH factor that comes out of IDEA physics at each 3D gridpoint, but the technical details of this implementation have only started to be explored. We will also need to decide what to do on the first timestep when this global mean is unavailable.

ZhuxiaoLi66 commented 5 years ago

the latitude setting in the plotting NCL code has been double checked by checking the Temp. Latitudinal pattern of January and July. , the setting seems no problem. Zonal_mean_T_201301_lat_check zonal_mean_T_201307_lat_check

akubaryk commented 5 years ago

ee8451e introduces a new module for these globally integrated JH values.

Since the physics calls are done in many slices, a larger 4D array stores the JH values. These stored values are passed out of idea_phys (from idea_ion from GetIonParams) as JH * den * ( geopotential_height(k+1) - geopotential_height(k-1) ) / 2, not including the top layer. In the module for the integral calculation, the latitudinal and longitudinal arc lengths are calculated as r_earth * dlat_r and r_earth * (2*pi / lons_per_lat_band) * coslat_r) respectively. This volume factor is multiplied by the stored values and summed over the entire array. Then an mpi_allreduce sums across processors.

I can't effectively test this branch with the ongoing maintenance until tomorrow, but I am hopeful that most of the code to deliver the hemispheric JH integrals is now in global_jh_integral.

timfullerrowell commented 5 years ago

Thanks for update Joe. Looks good to me.

On Tue, Jul 2, 2019 at 10:57 AM akubaryk notifications@github.com wrote:

ee8451e https://github.com/SWPC-IPE/WAM-IPE/commit/ee8451eb35c8fa6f8b037b8369ca107184668bf3 introduces a new module for these globally integrated JH values.

Since the physics calls are done in many slices, a larger 4D array stores the JH values. These stored values are passed out of idea_phys (from idea_ion from GetIonParams) as JH den ( geopotential_height(k+1) - geopotential_height(k-1) ) / 2, not including the top layer. In the module for the integral calculation, the latitudinal and longitudinal arc lengths are calculated as r_earth dlat_r and r_earth (2pi / lons_per_lat_band) coslat_r) respectively. This volume factor is multiplied by the stored values and summed over the entire array. Then an mpi_allreduce sums across processors.

I can't effectively test this branch with the ongoing maintenance until tomorrow, but I am hopeful that most of the code to deliver the hemispheric JH integrals is now in global_jh_integral.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/SWPC-IPE/WAM-IPE/issues/303?email_source=notifications&email_token=AH5BFOHGHLXPJLQIPDHULQDP5OCHVA5CNFSM4HWV4EQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZB5F7I#issuecomment-507761405, or mute the thread https://github.com/notifications/unsubscribe-auth/AH5BFOGK6E4M45SS457ZAGLP5OCHVANCNFSM4HWV4EQQ .

ZhuxiaoLi66 commented 5 years ago

Thanks for the update, Adam.

akubaryk commented 5 years ago

Branch new_weimer_poynting now contains ee8451e and some additional fixes to get it to compile/run. Currently it outputs jh.nc4 in the RUNDIR, a per-timestep record of what it calculates as the integral in each hemisphere (jh_sh and jh_nh). The values seem to be off by several orders of magnitude according to data provided by Martin. I found that it is the lead processor that contributes the vast majority to the sum:

[1]  407656585290.923
[4]  0.000000000000000E+000
[5]  184958790809666.
[6]  309057951486.446
[9]  190231940537.729
[10] 182747179577450.
[12] 0.000000000000000E+000
[14] 301972764884835.
[15] 362314599024073.
[13] 319806623313842.
[8]  41136548155.0455
[11] 0.000000000000000E+000
[2]  0.000000000000000E+000
[7]  19547608345.0608
[3]  195154270688.382
[0]  7.020624978748218E+017

Maybe some debugging to be done. At this point I may try to pass out the JH arrays (along with geopotential height, density, etc. as needed in the integral calculation) as 3D physics fields in NetCDF format so we can manually verify the structure and magnitude? Ideas welcome.