Feature/wjiang/vertical indices

[weiyuan-jiang]

Description

This PR tries to improve the performance of vertical interpolation by saving the indexes and the linear weight.

Related Issue

Motivation and Context

How Has This Been Tested?

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Trivial change (affects only documentation or cleanup)

Checklist:

• I have tested this change with a run of GEOSgcm (if non-trivial)
• I have added one of the required labels (0 diff, 0 diff trivial, 0 diff structural, non 0-diff)
• I have updated the CHANGELOG.md accordingly following the style of Keep a Changelog

[weiyuan-jiang]

@bena-nasa , at this point, only the case ( size(ptrin,3) == size(this%pl3d,3) ) is implemented. But the results are not correct. Do I miss any step?

[weiyuan-jiang]

@bena-nasa It is zero diff now. I am wondering if we need to implement the edge variables.

[mathomp4]

@weiyuan-jiang You might need to do the conflict resolution on the multigroupserver. I took a look and I'm not sure which ones are right.

[weiyuan-jiang]

@weiyuan-jiang You might need to do the conflict resolution on the multigroupserver. I took a look and I'm not sure which ones are right.

I messed the local and remote. I will fix it.

[weiyuan-jiang]

@tclune @bena-nasa A temporary test shows the improvement of one output on collection of geosgcm_prog. ( those timer will be removed before merging). How do we get total time for all ranks for that timer?
...
...
new_way_total: 7.074475288391113E-004
old_way_total: 7.667481899261475E-003
new_way_total: 6.859898567199707E-004
old_way_total: 7.682621479034424E-003
new_way_total: 6.768256425857544E-004
old_way_total: 7.748976349830627E-003
new_way_total: 6.947368383407593E-004
old_way_total: 7.644027471542358E-003
new_way_total: 7.014274597167969E-004
old_way_total: 7.637321949005127E-003
new_way_total: 7.352679967880249E-004
old_way_total: 7.577374577522278E-003
new_way_total: 7.223784923553467E-004
old_way_total: 7.627740502357483E-003
new_way_total: 7.190555334091187E-004
old_way_total: 7.645726203918457E-003
...
...

[tclune]

(1) I don't think you want the total. You might want max.

(2) The MPI support is all through DistributedProfiler, but you are using a simple timer. For now you'll have to do MPI reduce (sum/max/...) calls directly with the relevant communicator.

[weiyuan-jiang]

Ah, I am using my eyes and find out the max. There are only 9 variables with vertical dimension in that collection ( excluding ZLE)
new_way_total: 7.738322019577026E-004
old_way_total: 1.003018021583557E-002

[tclune]

You could also use pFlogger to redirect the output to a different file for each MPI rank. This would allow a simple script to find max and such; assuming that all server processes called the same pflogger sequence.

[weiyuan-jiang]

More realistic c360 run. max

new_way_total: 2.666312456130981E-002
old_way_total: 0.348897576332092

[weiyuan-jiang]

This PR now is zero-diff with the PR #2251

[mathomp4]

Seems to be zero-diff.