Constituent index lookup #622
Conversation
ccpp_constituent_index: Lookup index constituent by name ccpp_constituent_indices: Lookup indices of consitutents by name Add tests of this functionality into advection_test Minor code cleanup Update DDThost test for new CCPP source file
gold2718
requested review from
climbfuji,
dustinswales,
mwaxmonsky,
peverwhee,
grantfirl and
mkavulich
as code owners
| if (initialized) then | ||
| if (size(const_inds) < size(standard_names)) then | ||
| errcode = 1 | ||
| errmsg = subname//': const_inds too small' |
There was a problem hiding this comment.
maybe a slightly clearer error message?
errmsg = subname//': const_inds array too small. Must be greater than or equal to the size of standard_names'
| end if | ||
| end subroutine ccpp_initialize_constituent_ptr | ||
|
|
||
| subroutine ccpp_constituent_index(standard_name, const_index, errcode, errmsg) |
There was a problem hiding this comment.
General design question - what is the anticipated usage of these interfaces on the physics side?
As written, the code would return int_unassigned for the index if the provided constituent isn't present. So would it be expected that the physics would check for int_unassigned after calling ccpp_constituent_index?
There was a problem hiding this comment.
Great question. The benefit I see in returning int_unassigned is you can include logic for handling configurations that do not have all the constituents you might be looking for. On the other hand, it complicates just looking for errcode. Feedback @climbfuji, @dustinswales, everyone?
There was a problem hiding this comment.
@gold2718 @peverwhee I haven't thought through how we would tackle implementing the constituents feature in the UFS, so I don't have a strong opinion. On the physics side, having to check that index ne int_unassigned before using index seems sensible to me. At least with my (limited) understanding.
There was a problem hiding this comment.
I think this makes sense. Someone may want to iterate over constituents to see what is available and what not. That is, not every call to this scheme should result in errflg /= success.
| call ccpp_constituent_index(const_std_name, const_index, errflg, errmsg) | ||
| if (errflg == 0) then | ||
| call ccpp_constituent_indices(test_stdname_array, const_inds, errflg, errmsg) | ||
| end if |
There was a problem hiding this comment.
would it be worthwhile to also test that calling ccpp_constituent_indices with a constituent that's NOT in the object doesn't produce an error?
There was a problem hiding this comment.
Yep, will do, good call.
| end if | ||
| end subroutine ccpp_initialize_constituent_ptr | ||
|
|
||
| subroutine ccpp_constituent_index(standard_name, const_index, errcode, errmsg) |
There was a problem hiding this comment.
@gold2718 @peverwhee I haven't thought through how we would tackle implementing the constituents feature in the UFS, so I don't have a strong opinion. On the physics side, having to check that index ne int_unassigned before using index seems sensible to me. At least with my (limited) understanding.
Implement constituent index lookup routines
privatepointer to the CCPP constituent object so many more interfaces could easily be createdUser interface changes?: Yes
- New routines available to CCPP schemes
Addresses #597
Testing:
test removed: None
unit tests: PASS
system tests: Added functionality to advection test, PASS
manual testing: NA