Abnormal shflux when QCORRECTION is defined in ROMS 1147

[sunke20021]

Hello, all
My model run well with ROMS 783. Recently, I updated the latest ROMS 1147. Everything is fine, with the output u, v, w and salinity were all similar with the results of ROMS 783. But the abnormal stflx(i,j,itemp) lead to abnormal temperature. In my application, QCORRECTION is defined, and I input the dqdsst and sst data. These data were correctly read by the model, evidenced by the log file.
I notice the stflx(i,j,itemp) is calculated in set_vbc.F by the code "stflx(i,j,itemp)=stflx(i,j,itemp)+dqdt(i,j)*(t(i,j,N(ng),nrhs,itemp)-sst(i,j))", and before be writed by wrt_his.F, stflx(i,j,itemp) is unchanged. But my output shflx(i,j,itemp) seem always equal to the input shflux(i,j,itemp). With ROMS 783, the output shflx(i,j,itemp) was modified by the dqdsst and sst. I do not know why.
So I changed code of set_vbc.F to "stflx(i,j,itemp)=0" the check, the output shflux is 0 as expected. But when I tried the "stflx(i,j,itemp)=dqdt(i,j)" or "stflx(i,j,itemp)=sst(i,j)", the output shflx(i,j,itemp) is equal to the input shflux(i,j,itemp) again.
Any suggestions would be appreciated.

[sunke20021]

And how can I reverse from ROMS 1147 to an earlier version use SVN, like ROMS 916.

[wilkin]

Are you using #define ANA_DQDSST to set dqdt with the analytical functional file? If so, check analytical.f90 in the Build directory to see what code is actually there. Maybe dqdt is set to zero. If you are reading it from netcdf, the logfile should report the vales read. Check for that.

To revert to a different svn version, use

Code: Select all

svn update -r N

where N is the version number you want.

[sunke20021]

Hi, John.

Thank you very much!

I did not define ANA_DQDSST and BULK_FLUX, and the "dqdt" in ana_dqdsst.h is still set to ???. My input dqdsst was read correctly in logfile:
GET_2DFLD_NF90 - surface net heat flux sensitivity to SST, 0001-12-15 00:00:00.00
(Grid=01, Rec=12, Index=1, File: sub_ECS_frc.nc)
(Tmin= 15.0000 Tmax= 345.0000) t = 345.0000
(Min = -1.09291988E-05 Max = -4.45711885E-06) regrid = F

I notice the main differences of "set_vbc.F" between ROMS 783 and ROMS1147 is
> DO j=JstrR,JendR
> DO i=IstrR,IendR
> stflx(i,j,itemp)=stflux(i,j,itemp)
> btflx(i,j,itemp)=btflux(i,j,itemp)
> END DO
> END DO

If this part is commented, the initial stflx(i,j,itemp) is set to its IniVal=0 in mod_forces.F. After that, my test results seem normal, and "stflx(i,j,itemp)" can be modified by the equation "stflx(i,j,itemp)=stflx(i,j,itemp)+dqdt(i,j)*(t(i,j,N(ng),nrhs,itemp)-sst(i,j))". I can also use the "stflx(i,j,itemp)=dqdt(i,j)" to recheck the input "dqdt", although it is multiplied by rho0*Cp I think.
So, I doubt that in ROMS1147 there is some code overide the effect of "set_vbc.F" on "stflx(i,j,itemp)" might through "stflux(i,j,itemp)". I struggled for a week and rechecked all codes contain "stflx" or 'stflux'. But as a beginner of debug, I have not find any clues. Can you help me?

By the way, could it be a problem with the compiler version or other configurations. I use ifort: intel-2016.sh and mvapich2-2.0-intel.sh.

[wilkin]

(Min = -1.09291988E-05 Max = -4.45711885E-06) regrid = F

Those seem like very small numbers for dQdT.

varinfo.yaml indicates that the assumed units are watt meter-2 Celsius-1

ROMS works in kinematic units so this factor is divided by rho0*Cp to convert it to m/s. Then in set_vbc.F the Qcorrection is dqdt*(deltaSST) for stflx units of Celsius*m/s.

So, your input values for dqdt of order -1E-05 are converted to -1E-05/(1025*3985) = -2E-12. When multiplied by a small deltaSST the correction is minute. I think this is your problem.

In ana_dqdsst the scaling by rho0*Cp is implied. The example code there has:

Code: Select all

      fac=day2sec/30.0_r8            ! 30 day relaxation scale 1/s/decC
      DO j=JstrT,JendT
        DO i=IstrT,IendT
          dqdt(i,j)=fac*Hz(i,j,N(ng))

so if the surface layer thickness were Hz(N) = 1.0 m, for the timescale of 30 days dQdT/(rho)*Cp) = 1.0/(30*86400) = 3.8E-07 and that is 10,000 times larger than your value.

Don't be misguided by the comments in varinfo.yaml. They should be:

Code: Select all

  units:          watt meter-2 Celsius-1                           # Input:  [Watt/m2/Celsius]
  field:          d(Q)/d(SST)                                      # [m/s]

[arango]

I always recommend Users to keep the ROMS code up to date. Every time that the code is changed to correct bugs or improvements, detailed information is provided in the trac tickets. Users should never ignore that information, even if they are not updating the code. For example, the surface fluxes were redesigned because of coupling and data assimilation.

Please check the following trac tickets:

https://www.myroms.org/projects/src/ticket/806
https://www.myroms.org/projects/src/ticket/869
https://www.myroms.org/projects/src/ticket/870

[sunke20021]

Hi, John.

Thank you very much!

My input dQdSST in forcing file ranges from -52 to -14. The reported range in logfile (Min = -1.09291988E-05 Max = -4.45711885E-06) was already divided by rho0*Cp. I think it was done in inp_par.F by the code "cff=1.0_r8/(rho0*Cp); Fscale(iddQdT,ng)=cff*Fscale(iddQdT,ng)".
So I don't think the input dQdSST is a problem.

As mentioned before about the code in set_vbc.F. When "stflx(i,j,itemp)=stflx(i,j,itemp)+dqdt(i,j)*(t(i,j,N(ng),nrhs,itemp)-sst(i,j))" is changed to "stflx(i,j,itemp)=0.0_r8" or "stflx(i,j,itemp)=1.0_r8", the output stflux is 0 and 1*rho0*Cp, respectively. It is reasonable.
However, if it is changed to "stflx(i,j,itemp)=dqdt(i,j)", the output stflux is equal to my input stflux in forcing file. It should be equal to dqdt, right? This makes me very confused.
I did another test. Define ANA_DQDSST, and set dqdt to 0 in ana_dqdsst.h. Change the code in set_vbc.F to stflx(i,j,itemp)=dqdt(i,j). The output stflux is still equal to my input stflux in forcing file. It is abnormal, right?

I have checked all these code modification in my Build_roms, and they have been executed.

Ke Sun

[sunke20021]

Hi, arango.

Thank you very much for your reply.
I will follow trac tickets from now on. I read these tickets you mentioned and other tickets about "stflux" and "dqdt". But I still cannot figure out my question, and I will continue to dig deeper.