Remove UM trajectory initialization from real

[smileMchen]

TYPE: feature removed

KEYWORDS: UM trajectory, NCAR ACOM trajectory

SOURCE: Internal

DESCRIPTION OF CHANGES:
The UM trajectory option has been replaced by NCAR ACOM trajectory option. Therefore, the initialization for UM
trajectory (in the real program) is no longer needed.

LIST OF MODIFIED FILES:
M dyn_em/module_initialize_real.F

TESTS CONDUCTED:
(1) A single test case has been conducted to demonstrate that the UM trajectory no longer works. NCAR ACOM trajectory option gives expected results.
(2) Jenkins test is done successfully.

RELEASE NOTE: Not necessary

[smileMchen]

@davegill @weiwangncar @dudhia @kkeene44
All,
Since WRFv3.9.1, the UM trajectory option has been replaced by the NCAR ACOM trajectory option. While the ACOM trajectory option works fine, the UM trajectory does have its advantages.
Dave and I discussed this issue whether to recover the UM trajectory option. We are not sure yet how much coding work will involve. Our initial attempt failed due to problems possibly related to memory and MPI issues. We don't know yet the exact reason.
We leave the discussion to the group whether to keep both trajectory options, or it is just fine to stay with the NCAR ACOM option.

[dudhia]

Can you say what the advantages of the UM option are? Thanks.

…

On Tue, Dec 29, 2020 at 3:54 PM smileMchen ***@***.***> wrote: @davegill <https://github.com/davegill> @weiwangncar <https://github.com/weiwangncar> @dudhia <https://github.com/dudhia> @kkeene44 <https://github.com/kkeene44> All, Since WRFv3.9.1, the UM trajectory option has been replaced by the NCAR ACOM trajectory option. While the ACOM trajectory option works fine, the UM trajectory does have its advantages. Dave and I discussed this issue whether to recover the UM trajectory option. We are not sure yet how much coding work will involve. Our initial attempt failed due to problems possibly related to memory and MPI issues. We don't know yet the exact reason. We leave the discussion to the group whether to keep both trajectory options, or it is just fine to stay with the NCAR ACOM option. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1353 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77FXXKKMOTZGDTRDJYTSXJM2XANCNFSM4VNV56KQ> .

[smileMchen]

@dudhia
Jimy,
The UM trajectory is easily initialized and the output can be controlled by the history interval.
The ACOM option needs wrfinput_traj as input and output is every time step.

[davegill]

@dudhia @weiwangncar @kkeene44 @smileMchen
The original simple UM trajectory:

1. just i,j,k location
2. initialized in real

The new ACOM trajectory:

1. values of user selectable fields at each trajectory point
2. initialization is via lat/lon and a separate input file

[dudhia]

Seems worth a try in my opinion

…

On Tue, Dec 29, 2020 at 4:25 PM Dave Gill ***@***.***> wrote: @dudhia <https://github.com/dudhia> @weiwangncar <https://github.com/weiwangncar> @kkeene44 <https://github.com/kkeene44> @smileMchen <https://github.com/smileMchen> The original simple UM trajectory: 1. just i,j,k location 2. initialized in real The new ACOM trajectory: 1. values of user selectable fields at each trajectory point 2. initialization is via lat/lon and a separate input file — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1353 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77ABPLM5QPAPTMVEDJ3SXJQOPANCNFSM4VNV56KQ> .

[davegill]

Folks,
Ming pointed me to the original PR
#84

There was no attempt to provide traj_opt=2 and keep the original traj_opt=1. There are lots of places where the original trajectory code was overwritten. It would be a large effort to bring back the original capability.

[weiwangncar]

@dudhia @davegill @smileMchen Apart from initialization, the ACOM code can compute meteorological values along the trajectory, which was the major enhancement.

[dudhia]

Maybe just making it easier to use or having reasonable defaults and example files is sufficient.

…

On Tue, Dec 29, 2020 at 4:40 PM weiwangncar ***@***.***> wrote: @dudhia <https://github.com/dudhia> @davegill <https://github.com/davegill> @smileMchen <https://github.com/smileMchen> Apart from initialization, the ACOM code can compute meteorological values along the trajectory, which was the major enhancement. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1353 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77H2JIMUIWKJFZ5UJGDSXJSGZANCNFSM4VNV56KQ> .

[davegill]

@weiwangncar @dudhia @smileMchen
Folks,
None of the new trajectory is handled via the registry. A number of mods overwrote the original code. There is no way to tease out traj_opt=1 vs traj_opt=2 (for example), they are all mixed together. I ran a simple trajectory. I got all of the info for the ACOM trajectory. However, I also got the original data in the standard wrfout_d01* file.

This seems like quite an effort to split them apart. This PR cleans up code that is no longer used. I think that should be done, as users are going to be very confused why no trajectories are initialized after they have put them into the real program.

Do we have utilities to process the ACOM traj output files?

[weiwangncar]

No, we don't. We didn't have anything to plot the UM trajectories either, at least not that I'm aware of. I've already changed my Option talk to reflect the new option. Also should we leave this PR to 4.3?

[davegill]

@weiwangncar @smileMchen @dudhia @kkeene44

should we leave this PR to 4.3?

That would give us time to decide what to do. However, I think that the decision is clear - UM traj is gone, and ACOM traj is the way we operate.

[dudhia]

I agree with this. We need to try to make the ACOM trajectories easy to use with some default settings and example files that work. Jimy

…

On Thu, Jan 7, 2021 at 9:06 PM Dave Gill ***@***.***> wrote: @weiwangncar <https://github.com/weiwangncar> @smileMchen <https://github.com/smileMchen> @dudhia <https://github.com/dudhia> @kkeene44 <https://github.com/kkeene44> should we leave this PR to 4.3? That would give us time to decide what to do. However, I think that the decision is clear - UM traj is gone, and ACOM traj is the way we operate. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1353 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEIZ77FFVZIXXL6YC5YMMSLSY2ACTANCNFSM4VNV56KQ> .

[davegill]

@smileMchen @weiwangncar @dudhia
Folks,
Regardless of the documentation status for the ACOM trajectory, this PR should be merged. It gets rid of code that would be confusing, as it is not utilized. If we are in agreement, I'll approve it.

[weiwangncar]

@davegill @smileMchen @dudhia I'm ok with it...

[matzegoebel]

In module_initialize_ideal.F the template for initializing trajectories is still there. Shouldn't it also be removed then?