Transmit a variable from solve_em to a microphysics scheme

[xuzhou12]

Hello,
I appreciate if anyone would like to help me out of this question,
In my research we want to add a passive tracer in model. This part has been mentioned in forum,which is coded in dyn_em/solver_em.
Then we want to see the effect of this passive tracer onnee the microphysical process using SBM. So
I need to add this tracer to a microphysical variable, say QNIN.
Following the wrf output variable process, I declare a new variable in SBM
tr_two
and transmit to module_microphysics_driver TR_TWO. TR_TWO=tr_two
and then to solver_em, where the tracer2 is calculated.
When I linked them together, I found that TR_TWO is zero, which is TR_TWO=tracer(ims,kms,jms,P_N_TWO), while tracer(ims,kms,jms,P_N_TWO) is not zero in solver_em.

I am not understanding where I made mistakes. Why they can not transmit as the variable output from microphysal schemes.

In case of my expression not clear, please find my attached file related. Here are the variables name tr_two in module_mp_full, TR_TWO in module_microphysics_driver, and tracer( ims,kms,jms,P_N_TWO) in solver.

THANK YOU VERY MUCH FOR YOUR HELP.

 

[xuzhou12]

Sorry just want to correct that the passive tracer is edited in solve_em, it is not an exactly variable, The tracer edited in solve_em aims to make the plume continues every time step.

However, I have no idea how to hook this tracer to to SBM scheme so that making an effect on microphysical process.

 

[kwerner]

Hi,
I spoke to our physics specialist about this. They said you should make sure it is listed in a used package (it probably is, if it's non-zero), and check how it is declared in the microphysics driver, where it should be a 3d array.

 

[xuzhou12]

Hi,
I spoke to our physics specialist about this. They said you should make sure it is listed in a used package (it probably is, if it's non-zero), and check how it is declared in the microphysics driver, where it should be a 3d array.

Hello, thank you for your reply. I think the change in solve_em can not be transmitted to microphysical scheme as you mentioned.
According to your suggestions, I used u_phy to take a simple test.
In solve_em, I take a new variable say new_variable = 1.0*grid%u_phy. (this line is added at the beginning after CALLs and ALLOCATE (max_vert_cfl_tmp(grid%num_tiles)) ALLOCATE (max_horiz_cfl_tmp(grid%num_tiles))).


Then CALL microphysics_driver(...
TR_TWO=new_variable)

Then in module_microphysics_driver.F, CALL sbm(...
tr_two=TR_TWO)
I found that the tr_two = 0.00000E00 which is not the expected u value.

I don't know what is the reason, but I really want to share this result so that anyone would like to help.

Thanks

 

[kwerner]

Does this mean you have been able to move past your original issue?

 

[xuzhou12]

Does this mean you have been able to move past your original issue?

Hello,
Thank you for your reply, I think that my original problem is how to transmit a variable that is calculated in solve_em to microphysics scheme. However the answer is no. As the variable is re-calculated solve_em ( as an example u_phy is edited to 0.01*u_phy) I am not able to transmitted it to the microphysics scheme sucessfully.
What I did is adding this line into solve_em after all CALL functions.
grid%u_phy=grid%u_phy *0.01
I can't figure out why this change can't transmit.
It is really appreciate if someone would like to help me out.

Regards,
xu

 

[kwerner]

Hi Xu,
I first would like to apologize for the long delay in response. We were busy preparing for our WRF tutorial and have gotten behind on forum responses. Are you still struggling with this? If so, can you let me know which version of WRF you are working with? I tried comparing your files with some of the more recent model versions and there are over 200 differences in the files. Also, did you make any modifications to the registry file? If so, can you attach that file, as well? If you're adding a new variable, you'll need to make sure you added it to the Registry.EM_COMMON file, and then cleaned the code and recompiled. I'm sure you've already followed the steps in this presentation, but just in case you've not seen it, I wanted to share it.

I also want to let you know that there likely will be another delay in my response, as I will be out of the office until after Aug 11th. I apologize for the inconvenience and thank you for your patience. If you need help before then, you can post your inquiry as a new question so that perhaps my colleague will be able to respond. If you do that, please come back to this post and let me know you did so, by adding the link to that post. Thank you!

 

[xuzhou12]

Hi Xu,
I first would like to apologize for the long delay in response. We were busy preparing for our WRF tutorial and have gotten behind on forum responses. Are you still struggling with this? If so, can you let me know which version of WRF you are working with? I tried comparing your files with some of the more recent model versions and there are over 200 differences in the files. Also, did you make any modifications to the registry file? If so, can you attach that file, as well? If you're adding a new variable, you'll need to make sure you added it to the Registry.EM_COMMON file, and then cleaned the code and recompiled. I'm sure you've already followed the steps in this presentation, but just in case you've not seen it, I wanted to share it.

I also want to let you know that there likely will be another delay in my response, as I will be out of the office until after Aug 11th. I apologize for the inconvenience and thank you for your patience. If you need help before then, you can post your inquiry as a new question so that perhaps my colleague will be able to respond. If you do that, please come back to this post and let me know you did so, by adding the link to that post. Thank you!

Sorry, I have to come back to this problem again.
my WRF version is V4.2.1 in Cheyenne HPC under the direction /glade/scratch/zhouxu/WRF-4.2.1. What I want to do is transport the recalculated tracer(i,k,j, P_N_TWO) to module_mp_full.F where the tracer is assumed to take part in the physical process. Specifically, in dyn_em/solve.F the recalculated tracer(i,k,j,P_N_TWO) is used in CALL microphysics_driver (.... tra=tracer(ims,kms,jms,P_N_TWO)....). In phys/module_microphysics_driver.F,
tra is reclared:
SUBROUTINE microphysics_driver(.....,tra,.....)
REAL, DIMENSION( ims:ime, kms:kme, jms:jme ),OPTIONAL, INTENT(INOUT ) :: tra
CASE (FULL_KHAIN_LYNN)
CALL sbm(...,tr_two=tra,...)

In phys/module_mp_full.F,
I found tr_two = 0.00000E0, which is not the expected tracer(ims,kms,jms,P_N_TWO).

I am quite confused where I am wrong, how can I correct the error so that get the correct value of tr_two.

From the wrfout files, I am able to get the expected value of the tracer(ims,kms,jms,P_N_TWO). So I am thinking it may be some mistakes on trasnporting the parameters.
Please find the related fortran files and namelist below.