Comments (8)
@brhillman
Thanks for bringing this to our attention. Certainly looks as surfelev should not be declared as optional.
@rodrigoguzman-lmd Thoughts?
from cospv2.0.
@dustinswales @brhillman
Thanks for your messages, and sorry for the delayed answered. Yes, surfelev should definitively not be declared as optional. Dustin, what do you think if I open a new pull request where I could fix this and the bug concerning the opaque temperature diagnostics?
from cospv2.0.
@dustinswales @brhillman
Actually, it is not the COSP_OPAQ routine which declares surfelev as optional, it is the lidar_column routine which is in the same file (lidar_simulator.F90). So the title of this issue is not appropriate. The lidar_column routine declares surfelev as optional because it is only used by the CALIPSO simulator so far. @dustinswales , what shall we do, leave it as it is for the time being or declare surfelev as not optional in lidar_column and, hence, add this compulsory argument to the other lidar platform calls even if they don't use the surfelev variable so far?
from cospv2.0.
Oh, apologies, I might have had to add the optional to get it to run, because it's optional in lidar_column
but non-optional in cosp_opaq
, which is called from lidar_column
. So either way this is a problem, because surfelev
may not be present in lidar_column
but is assumed present (required) in cosp_opaq
. But I'll fix the description to be clear about this.
from cospv2.0.
@brhillman @rodrigoguzman-lmd @RobertPincus
Sorry for the late response, just now getting caught up on all things COSP.
After going through the code, I vote to keep surfelev
as an optional input to lidar_column()
. The reasoning is that in cosp.F90
, lidar_simulator()
is used by three different simulators (Calipso, ATlid, ground-based 532nm lidar), but only the Calipso simulator requires surfelev
(to call cosp_opaq()
, which it always does). Additionally, surfelev
is protected throught lidar_column()
with lcalipso
flags.
Another option would be to have two interfaces to lidar_column()
, but I'm in favor of the former.
from cospv2.0.
@dustinswales Your logic is sound. Does it imply we should see if @brhillman is willing to open a PR with changes to protect against using the variable when it's not provided?
from cospv2.0.
@dustinswales Your logic is sound. Does it imply we should see if @brhillman is willing to open a PR with changes to protect against using the variable when it's not provided?
@RobertPincus
The only place we need to add code is to the subroutine cosp_errorCheck()
. There are three checks performed, 0) Are all fields allocated for requested simulators? 1) Are provided fields in range? 2) Are input fields sized consistently?
We would need to add logic in all three parts for both the Calipso and Cludsat simulator, as they both rely on surfelev
.
@brhillman Would you be willing to open a PR?
from cospv2.0.
Closed.
See #64
from cospv2.0.
Related Issues (20)
- MODIS Optical_Thickness_vs_ReffICE and Optical_Thickness_vs_ReffLIQ not masked for night columns HOT 3
- Striping caused by vertical interpolation routine HOT 15
- Example data for tests do not include any night columns HOT 2
- Allocation issue with MODIS/Cloudsat joint-products HOT 1
- cosp_diag_warmrain has wrong dimensions for variable frac_out / design flaw HOT 2
- cosp2_test reference (test) output is missing variables & needs versioning. HOT 4
- Python test script does not note occurrence of outputs that are not in the test dataset (Version check?) HOT 6
- Remove COSPv1.4 interface HOT 5
- Test case using global snapshot HOT 5
- Encoding version information in the KGO HOT 7
- CI test ifort broken HOT 1
- Implementation of CLARA simulator HOT 14
- hgt_matrix_half is used inconsistently HOT 1
- Masking fix in cosp_diag_warmrain? HOT 4
- Calculation of cloudsat_preclvl_index fails when use_vgrid=.false. HOT 4
- Missing type specifier causing crash on Cori-KNL in running debug mode HOT 6
- Allocation of radar lookup table and delete unused variables
- download_test_data.sh drive links HOT 3
- add MODIS joint histgram diagnostics
- Inconsistent unit labels for hgt_matrix
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cospv2.0.