Edge level arrays out-of-bounds in Lighting_mod

[atrayano]

@christophkeller In GEOS, the indexing convention for edge variables is 0:LM. Lightning_mod.F90 references these 3 variables: PLE, cnvMfc, geoPotHeight (passed in from Moist as ZLE) from 1:LM+1 - around lines 916-928 in Lightning_mod.F90
This issue was exposed by requesting MAPL to always allocate all exports, which essentially enabled calling get_hemcoFlashrate - equivalently we could have asked for LFR_GCC in History, and compiling GEOS with debug flags. The compiler flagged cnvMfc, but all 3 vars have the same issue

[mathomp4]

@christophkeller @atrayano Has this been taken care of?

[atrayano]

@mathomp4 not yet (thanks for reminding me)

[christophkeller]

I just updated the lightning module and made a PR for the fix: #159
I'm also tagging @megandamon as the original creator of the lightning wrapper.

[mmanyin]

@atrayano and @christophkeller - Actually the original code was not in error, since all 3 of those fields are deferred shape arrays, and as such, have starting index 1. The edge-array convention may have been violated, but the code was indexing correctly. (BTW, the Lightning module development was handed off from Megan to me, and I have updates (working in Icarus) that should be incorporated into GIT, when time allows.)