-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make variables using filename_base consistant in length #43
make variables using filename_base consistant in length #43
Conversation
fv3_cap.F90
Outdated
@@ -74,7 +75,7 @@ module fv3gfs_cap_mod | |||
|
|||
type(ESMF_GridComp) :: fcstComp | |||
type(ESMF_State) :: fcstState | |||
character(len=80), allocatable :: fcstItemNameList(:) | |||
character(len=max_filename_len+14),allocatable :: fcstItemNameList(:) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is the "14" defined? This could be confusing and error-prone when the interpolation method is changed, such as "first_order_conservative". It seems a temporary fix, from that point of view, I would suggest just setting the length of all the character strings to "ESMF_MAXSTR". Not sure the reason to have the filenames exactly 255 characters. If we do want that, we need a different fix. Basically the filenames are the local file names, if developers want to write to a different directory, they can set that up in script level.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed and done.
Hi, Dusan,
Here is a fix from Jeff on model public release code to use the consistent
string length for model output file names. There should be no impact on the
current public release RT. Would you please test it and commit to the
public release code? Please let me know if you have any questions. Thank
you!
Jun
…On Wed, Jan 15, 2020 at 7:16 AM jedwards4b ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In fv3_cap.F90
<#43 (comment)>:
> @@ -74,7 +75,7 @@ module fv3gfs_cap_mod
type(ESMF_GridComp) :: fcstComp
type(ESMF_State) :: fcstState
- character(len=80), allocatable :: fcstItemNameList(:)
+ character(len=max_filename_len+14),allocatable :: fcstItemNameList(:)
agreed and done.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#43?email_source=notifications&email_token=AI7D6TOOE5NOMZN5QTWZ6BLQ535CFA5CNFSM4KG3W6VKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCR2HWMA#discussion_r366844849>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI7D6TOBDC6RE77ATVFUNCLQ535CFANCNFSM4KG3W6VA>
.
|
@jedwards4b, I'm getting the syntax error:
The line 10 in module_fv3_io_def.F90 should be:
Please update the code and push to this branch. |
Sorry - it's fixed now. Jim |
@climbfuji Do I need to take further action to get the ufs-weather-model updated? |
@jedwards4b You can submit a ufs-weather-model (ufs_public_release branch) PR with fv3atm submodule pointing to 1e3cdc1 |
Jeff,
Dusan looked your pull request and noticed that the ufs-weather-model pull
request corresponding to this change is missing. Without it we don't know
if the code is actually tested by the developer. Generally we don't accept
pull request without proof of testing(RT log files updated in the
ufs-weather-model repo). Sorry I did not check that pull request assuming
that part is done. So for this commit, Dusan/Dom is very kind to offer
doing testing, but if you have future updates, please test the fix first in
the app level so that we know the fix is actually working. Thank you for
your understanding!
Jun
…On Wednesday, January 15, 2020, jedwards4b ***@***.***> wrote:
Sorry - it's fixed now.
Jim
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#43?email_source=notifications&email_token=AI7D6TMC4EQBE4J5Z3R2TRDQ54NAJA5CNFSM4KG3W6VKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJAQB7I#issuecomment-574685437>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI7D6TMPFXMCKU3UDBG2RGDQ54NAJANCNFSM4KG3W6VA>
.
|
Hi Jun,
Are you suggesting that in order to submit a PR related to usage with the
CIME build and test system I should be required to run the NOAA internal
testing? Where is that documented? Eventually I would also expect that
NOAA users submitting PR's would run the cime based testing. But again we
are still putting that together, I think that we all need to be patient
with each other while we work out the process.
Thanks,
Jim
On Wed, Jan 15, 2020 at 8:01 AM junwang-noaa <[email protected]>
wrote:
… Jeff,
Dusan looked your pull request and noticed that the ufs-weather-model pull
request corresponding to this change is missing. Without it we don't know
if the code is actually tested by the developer. Generally we don't accept
pull request without proof of testing(RT log files updated in the
ufs-weather-model repo). Sorry I did not check that pull request assuming
that part is done. So for this commit, Dusan/Dom is very kind to offer
doing testing, but if you have future updates, please test the fix first in
the app level so that we know the fix is actually working. Thank you for
your understanding!
Jun
On Wednesday, January 15, 2020, jedwards4b ***@***.***>
wrote:
> Sorry - it's fixed now.
>
> Jim
>
> —
> You are receiving this because your review was requested.
> Reply to this email directly, view it on GitHub
> <
#43?email_source=notifications&email_token=AI7D6TMC4EQBE4J5Z3R2TRDQ54NAJA5CNFSM4KG3W6VKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJAQB7I#issuecomment-574685437
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AI7D6TMPFXMCKU3UDBG2RGDQ54NAJANCNFSM4KG3W6VA
>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#43?email_source=notifications&email_token=ABOXUGBMMECKEEKZLYRN5QDQ54QL3A5CNFSM4KG3W6VKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJATIXQ#issuecomment-574698590>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABOXUGHNOSGHKB54BC5OQUDQ54QL3ANCNFSM4KG3W6VA>
.
--
Jim Edwards
CESM Software Engineer
National Center for Atmospheric Research
Boulder, CO
|
Totally understand. I appreciate your patience as we need to know some
testing is done in order to maintain a working model for other release
teams to work on it, we can't directly commit the user proposed code
changes, reviewers may miss something. The test can be done on any machine
the developers have access, test log files can be attached to the issue.
This is actually for all developers including NOAA developers. Otherwise it
will take longer time for the commit as we need to do internal testing to
make the proposed code changes working properly. Thanks for your
understanding.
Jun
…On Wednesday, January 15, 2020, jedwards4b ***@***.***> wrote:
Hi Jun,
Are you suggesting that in order to submit a PR related to usage with the
CIME build and test system I should be required to run the NOAA internal
testing? Where is that documented? Eventually I would also expect that
NOAA users submitting PR's would run the cime based testing. But again we
are still putting that together, I think that we all need to be patient
with each other while we work out the process.
Thanks,
Jim
On Wed, Jan 15, 2020 at 8:01 AM junwang-noaa ***@***.***>
wrote:
> Jeff,
>
> Dusan looked your pull request and noticed that the ufs-weather-model
pull
> request corresponding to this change is missing. Without it we don't know
> if the code is actually tested by the developer. Generally we don't
accept
> pull request without proof of testing(RT log files updated in the
> ufs-weather-model repo). Sorry I did not check that pull request assuming
> that part is done. So for this commit, Dusan/Dom is very kind to offer
> doing testing, but if you have future updates, please test the fix first
in
> the app level so that we know the fix is actually working. Thank you for
> your understanding!
>
>
> Jun
>
> On Wednesday, January 15, 2020, jedwards4b ***@***.***>
> wrote:
>
> > Sorry - it's fixed now.
> >
> > Jim
> >
> > —
> > You are receiving this because your review was requested.
> > Reply to this email directly, view it on GitHub
> > <
> #43?email_source=
notifications&email_token=AI7D6TMC4EQBE4J5Z3R2TRDQ54NAJA
5CNFSM4KG3W6VKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5
WW2ZLOORPWSZGOEJAQB7I#issuecomment-574685437
> >,
> > or unsubscribe
> > <
> https://github.com/notifications/unsubscribe-auth/
AI7D6TMPFXMCKU3UDBG2RGDQ54NAJANCNFSM4KG3W6VA
> >
> > .
> >
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#43?email_source=
notifications&email_token=ABOXUGBMMECKEEKZLYRN5QDQ54QL3A
5CNFSM4KG3W6VKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5
WW2ZLOORPWSZGOEJATIXQ#issuecomment-574698590>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/
ABOXUGHNOSGHKB54BC5OQUDQ54QL3ANCNFSM4KG3W6VA>
> .
>
--
Jim Edwards
CESM Software Engineer
National Center for Atmospheric Research
Boulder, CO
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#43?email_source=notifications&email_token=AI7D6TPLAHJXPS232K6AEO3Q54RLZA5CNFSM4KG3W6VKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJAUIVQ#issuecomment-574702678>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI7D6TN4V6POT2CCX4YKR7TQ54RLZANCNFSM4KG3W6VA>
.
|
As I said I am happy to run tests but you still haven't told me what tests or how to run them. |
I am happy to run the tests on Cheyenne tonight and send @DusanJovic-NOAA the logs for updating the ufs-weather-model repo. Back to Boulder next week I am happy to "teach" folks how to run the regression tests on Cheyenne (straightforward as long as no new baselines are required, otherwise I will need to do that). |
@climbfuji This change which is critical for cime testing does not seem to be in 8394f36 of ufs-weather-model. This is why cime testing is failing on cheyenne. |
I just checked the latest version of the release,
which has
|
Sorry - my fault, my update failed to recurse into subdirectories - but now I get another error:
|
I would start from a fresh checkout ... github probably upset by the change in branch names (or you need to do recursive git submodule sync) |
it was actually the change in the remote source of atmos_cubed_sphere - fixed now. |
Hopefully this fixes the runtime error on Cheyenne! I would like to move (back) to Intel 19.0.2 with the next version of the NCEPLIBS. Currently we are on alpha01, hope that the next version will be ready for being tagged as beta01. |
If this fixes the issue on Cheyenne, can you please update the folks who were on the call just beforehand so that they are not under the assumption that the code is broken? |
If you are going to update compilers on cheyenne please consider intel/19.0.5 and gnu/9.1.0, yes I will update this mornings call attendees as soon as I complete testing. |
Sure - 19.1.0.x was my target. |
@climbfuji I believe I now have the latest code in ~jedwards/sandboxes/mrweather.feb10/ |
Lets continue this discussion here: ufs-community/ufs-mrweather-app#84 |
…hwrf-physics dtc/hwrf-physics: HWRF Ferrier-Aligo MP scheme updates
make variables using filename_base consistant in length
…_develop Update gsd/develop from NOAA-EMC develop
filename_base was declared with length 255, however it was then used with variables of length 80 creating an error that was difficult to track down. This makes the length of these variables consistant, it is needed for the proper naming of CIME testcase files. See issue ufs-community/ufs-mrweather-app#49