Plume re-enters the domain after several hours?

[zhipengpei]

Hi,
I have been trying to simulate a tracer plume for a idealize case with WRF-LES model. I have one domain with resolution of 300m. Simulating time is 6 hours. I was confused why the plume left the border and then re-entered the domain from another border (image below).

Actually, the easiest way to solve this problem is to increase the domain size so that the plume cannot reach the boundary (either by reducing the simulation time or by using a coarser resolution).

In addition, I was confused about the unit. For example, what is the rate of tracer release (I'm guessing 1 t/h?) and what are the units of simulated tracer (volume mixing ratio? )?

Appreciate for any help.

Thanks
Zhipeng Pei

 

[kwerner]

Hi Zhipeng,
If you are using the default namelist.input file for the em_les case, and haven't modified anything in the &bdy_control section, the reason this is happening is because the "periodic_y" parameter is set to "true," meaning the conditions that exit out of the y_end, will return at the y_start position, as if the 2 sides were connected. If you want the plume to be able to leave the domain and not re-enter, you should turn on the open* parameters (set them in a way that makes sense for your domain) and then turn off the periodic_y setting.

Regarding the unit - I've not done a tracer simulation, myself. Can you let me know if there is a specific variable you are interested in knowing about? Otherwise, I can try to figure it out and get back to you. Thanks!

 

[zhipengpei]

Thank you for your detailed response regarding re-entry domain.

I tried to simulate the methane plume. I need to know the volume mixing ratio at different heights to get the column concentration.

I referred to Blaylock's blog and was able to simulate the plume of gas (not sure what the units of concentration are). And I don't see the configuration about methane in this blog. Does this mean the same result for all trace gases? Won't the density of the gas have an effect?

Last, I have added the following statement to the solve_em.F file.

   IF (config_flags%tracer_opt .eq. 2) THEN
     DO j = (jde + jds)/2, (jde + jds)/2,  1
       DO i = 1*(ide + ids)/4, 1*(ide + ids)/4, 1
          IF ( ips .LE. i .and. ipe .GE. i .and. jps .LE. j .and. jpe .GE. j ) THEN
            tracer(i, 1, j, P_plume) = 1.
          END IF
       END DO
     END DO
   END IF

Can you tell me what the 1 here means? Does it mean the emission rate is 1 t/h? Thanks!

Best,
Zhipeng

 

[kwerner]

Hi Zhipeng,
Apologies for the delay. I was out of the office for the past week. Regarding the blog you're following, I'm not certain if they are using anything special for methane. From what I can gather, though, all tracers are unitless because they are passive tracers (and are scalars). You may find it helpful to watch the example shown in this video (although he is using tracer_opt=3, instead of =2). Go to the chapter of the presentation called "tracer example," starting just after 1:19:00.

In your question about the number "1," I assume you're referring to the line
tracer(i, 1, j, P_plume) = 1.

If so, that simply turns on the plume at the i and j location and level(s) you choose, where it's initialized to zero everywhere else, at every time step. The video I pointed you to explains that in more detail.

 

[Hyder Pang]

Hi Zhipeng,
If you are using the default namelist.input file for the em_les case, and haven't modified anything in the &bdy_control section, the reason this is happening is because the "periodic_y" parameter is set to "true," meaning the conditions that exit out of the y_end, will return at the y_start position, as if the 2 sides were connected. If you want the plume to be able to leave the domain and not re-enter, you should turn on the open* parameters (set them in a way that makes sense for your domain) and then turn off the periodic_y setting.

Regarding the unit - I've not done a tracer simulation, myself. Can you let me know if there is a specific variable you are interested in knowing about? Otherwise, I can try to figure it out and get back to you. Thanks!

Hi, kwerner.

Apologies for the inconvenience caused to you. I met the same problem as Zhipeng.

However, I wish for an open boundary condition for the tracer while periodical boundary conditions for the physics. So, it seems that I can not simply turn "periodic_x" to "false". As a result, I tried to modify "Solve_em.F" but failed.

Again, I apologise for any naive mistakes, as I am new to WRF. Your help will be great helpful to me.

The newly added source in "Solve_em.F" is as follows.

DO k = kds, kde, 1
    DO j = jds, jde, 1
        IF ( kps .LE. k .and. kpe .GE. k .and. jps .LE. j .and. jpe .GE. j ) THEN
            tracer(ide, k, j, p_CH4) = tracer(ide-1, k, j, p_CH4)
            tracer(ids, k, j, p_CH4) = tracer(ids+1, k, j, p_CH4)
        ENDIF
    ENDDO
ENDDO

The output column integrated tracer (turn a 3d scalar into 2d) is as follows.

 

[Hyder Pang]

I attempted to resolve this issue independently by reviewing the WRF source code and implementing the following modifications

step 1.
I added a new mode 's' to the function 'set_physical_bc3d' in the '\share\module_bc.F' directory, which enforces open boundary conditions instead of periodic boundary conditions.

periodicity_x:  IF( ( config_flags%periodic_x ) .AND. (variable /= 's')) THEN
    ! ...
ELSE
    ! ...
    open_xs: IF( (( config_flags%open_xs   .or. &
                       config_flags%specified .or. &
                       config_flags%nested            ) .and.  &
                         ( its == ids ) .and. open_bc_copy  ) .or. &
                    (variable == 's' .and. its == ids))  THEN
        !...
    ENDIF open_xs
    open_xe: IF( (( config_flags%open_xe   .or. &
                       config_flags%specified .or. &
                       config_flags%nested            ) .and.  &
                         ( ite == ide ) .and. open_bc_copy ) .or. &
                         (variable == 's' .and. ite == ide))  THEN
        !...
    ENDIF open_xe
END IF periodicity_x

I applied similar changes to the 'y' variable, respectively.

step 2.
In '\dyn_em\solve_em.F', I replaced all 'p' option with 's' for each call of function 'set_physical_bc3d'.

CALL set_physical_bc3d( tracer(ims,kms,jms,ic), 'z', config_flags,   &
                                     ids, ide, jds, jde, kds, kde,            &
                                     ims, ime, jms, jme, kms, kme,            &
                                     ips, ipe, jps, jpe, kps, kpe,            &
                                     grid%i_start(ij), grid%i_end(ij),                  &
                                     grid%j_start(ij), grid%j_end(ij),                  &
                                     k_start    , k_end-1                    )

Here is a quick test case with modifications above.


I hope this is helpful to anyone who encounters the same problem. I would like to extend a special thanks to ChatGPT for providing rough but instructive guidance on how and where to access useful contents by UCAR in a relatively short amount of time.

 

[kwerner]

@Hyder Pang
I am so glad you were able to receive assistance and figured out how to solve the issue. Thank you so much for updating the post with the solution!

 

[芋圆小饼干]

Hi, Hyder Pang.
Apologies for the inconvenience caused to you. I don't see the configuration about methane in this blog. Does this mean the same result for all trace gases? Won't the density of the gas have an effect?

 

[Hyder Pang]

Hi, Hyder Pang.
Apologies for the inconvenience caused to you. I don't see the configuration about methane in this blog. Does this mean the same result for all trace gases? Won't the density of the gas have an effect?

Hi,

I am delighted to deliver my opinions. As far as I know, most papers on space methane monitoring try to simulate the methane plumes as passive trace gas, e.g. Varon et al. (2018) and Kuhlmann et al. 2019. The density is relatively low, indicating it is reasonable to neglect compared to the transport of the atmosphere. Maybe you can refer to papers in this domain (atmospheric dynamics or pollutants dispersion) for more detailed knowledge.

I hope my anwser is correct and may help you.

 

[1750585724]

Hi,

I am delighted to deliver my opinions. As far as I know, most papers on space methane monitoring try to simulate the methane plumes as passive trace gas, e.g. Varon et al. (2018) and Kuhlmann et al. 2019. The density is relatively low, indicating it is reasonable to neglect compared to the transport of the atmosphere. Maybe you can refer to papers in this domain (atmospheric dynamics or pollutants dispersion) for more detailed knowledge.

I hope my anwser is correct and may help you.

Hi,
Apologies for the inconvenience caused to you. When i get the plume initialization working, some problems exist. There is no wrf.exe. Can you help me to solve this problem. I would like to hear your replay. Thank you!