All other topics about postprocessing model data (GrADS and other software), about other numerical weather prediction software (including WRF-NMM and WRF-ARW discussion unrelated to UEMS/WRF EMS), and general meteorology talk go in this forum.

I think that the fields you are mentioning come from UPP post-processing.
Perhaps radar reflectivity is the only one you can find ready into the direct model history output files.
So this seems to me an UPP trouble not an NNMB problem.

Hovewer I will try to check this, by running with the Thompson MP.
Currently I only run Ferrier-Aligo MP because, although it is less sophisticated, Thompson MP is 20% slower.
Let you know the results next week.

There is an important reason why you want to use the Thompson's scheme?

I discused this with UPP help desk and they were insisting that problem is not within UPP but model itself that does not send required fields to calculate those mentioned parameters (they determined it from logs I sent to them).

I discused this with UPP help desk and they were insisting that problem is not within UPP but model itself that does not send required fields to calculate those mentioned parameters (they determined it from logs I sent to them).

OK Ivan, I confirm that also in our model unipost do not output CAPE when you use Thompson MP.

I think it is an unipost bug and I think it can be easily fixed.

CAPE is calculated by DTC unipost in CALCAPE.f, where you can see that the CAPE calculation involves the water vapor mixing ratio 'qv'. Really it uses the specific humidity, that unipost calculate from 'qv' as it reads 'qv' from the NEMSIO file.

Now it happens that when you use thompson MP, unipost has a bug.

Infact by comparing the unipost logs that come out when processing the NEMSIO binary output files for 'fer_hires' and for 'thompson' MP, I have discovered that the only difference is that the log for the 'thompson' case has the following error:

qv mid layer 1
not found in NEMS file-Assigned missing values

and the error repeats for all the vertical levels 1,2 3, ...

This says that the file INITPOST_NEMS.f (the file where unipost read-in all NEMSIO variables) fails reading the 'qv', mixing ratio of water vapor.

In that file you can see that if it MP is 'thompson', INIPOST_NEMS.f pretend to read-in the var 'qv' (and when done, it converts 'qv' into the specific humidity).
But here it fails, because the NEMS-NMMB do not put the 'QV' variable into the NEMSIO output files.

I think this can be ealisy fixed, because fortunately NEMSIO files (both for 'fer_hires' and 'thompson') contains the specific humidity. It is named 'SPFH' in the NEMSIO file.

So we should try to solve this error modifying the file INITPOST_NEMS.f, by replacing the code:

VarName='spfh'
VcoordName='mid layer'
do l=1,lm
! ll=lm-l+1
ll=l
call getnemsandscatter(me,nfile,im,jm,jsta,jsta_2l &
,jend_2u,MPI_COMM_COMP,icnt,idsp,spval,VarName,VcoordName &
,l,impf,jmpf,nframe,q(1,jsta_2l,ll))
do j=jsta_2l,jend_2u
do i=1,im
q(i,j,ll) = spfh(i,j,ll)
end do
end do
end do ! do loop for l

Really? I compared 'fer_hires' and 'thompson' 24h runs for today 00Z and can't see great differences in precipitation and temperatures.
Differences exist in cloud fractions and consequently in downward sw radiation.
Need further investigation about this.
Perhaps NAMV4.0.0 enhancements have reduced the gap between 'fer_hires' and 'thompson'.

I discused this with UPP help desk and they were insisting that problem is not within UPP but model itself that does not send required fields to calculate those mentioned parameters (they determined it from logs I sent to them).

OK Ivan, I confirm that also in our model unipost do not output CAPE when you use Thompson MP.

I think it is an unipost bug and I think it can be easily fixed.

CAPE is calculated by DTC unipost in CALCAPE.f, where you can see that the CAPE calculation involves the water vapor mixing ratio 'qv'. Really it uses the specific humidity, that unipost calculate from 'qv' as it reads 'qv' from the NEMSIO file.

Now it happens that when you use thompson MP, unipost has a bug.

Infact by comparing the unipost logs that come out when processing the NEMSIO binary output files for 'fer_hires' and for 'thompson' MP, I have discovered that the only difference is that the log for the 'thompson' case has the following error:

qv mid layer 1
not found in NEMS file-Assigned missing values

and the error repeats for all the vertical levels 1,2 3, ...

This says that the file INITPOST_NEMS.f (the file where unipost read-in all NEMSIO variables) fails reading the 'qv', mixing ratio of water vapor.

In that file you can see that if it MP is 'thompson', INIPOST_NEMS.f pretend to read-in the var 'qv' (and when done, it converts 'qv' into the specific humidity).
But here it fails, because the NEMS-NMMB do not put the 'QV' variable into the NEMSIO output files.

VarName='spfh'
VcoordName='mid layer'
do l=1,lm
! ll=lm-l+1
ll=l
call getnemsandscatter(me,nfile,im,jm,jsta,jsta_2l &
,jend_2u,MPI_COMM_COMP,icnt,idsp,spval,VarName,VcoordName &
,l,impf,jmpf,nframe,q(1,jsta_2l,ll))
do j=jsta_2l,jend_2u
do i=1,im
q(i,j,ll) = spfh(i,j,ll)
end do
end do
end do ! do loop for l

Will try this...

I never tried something like that. Maybe it will work. Did you get radar reflectivity from Thompson?

Really? I compared 'fer_hires' and 'thompson' 24h runs for today 00Z and can't see great differences in precipitation and temperatures.
Differences exist in cloud fractions and consequently in downward sw radiation.
Need further investigation about this.

During winter tmp2m was much better than during summer when Ferriers overestimated much more than Thompson runs tmp2m over low land terrain.