Skip to content
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

Added nza again #141

Merged
merged 4 commits into from
Nov 11, 2019
Merged

Added nza again #141

merged 4 commits into from
Nov 11, 2019

Conversation

whaeck
Copy link
Member

@whaeck whaeck commented Nov 7, 2019

No description provided.

@whaeck whaeck requested a review from jlconlin November 7, 2019 15:03
@@ -358,14 +359,22 @@ subroutine acer
else if (iopt.eq.2) then
tempd=300
tscr=' '
nza=16
read(nsysi,*) matd,tempd,tscr
nza=3
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still don't like the default to be 3. While there wasn't an nza parameter previously, it was effectively defaulted to 1 as only 1 was required.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to keep backwards compatible behaviour. If a user has an input like this:

    4025 296 'zrzrh' /
    40090 0 0 /

and we use nza=1 by default, then the last two zeros may be read as the next input (the mt numbers, number of bins, etc.). Setting nza by default equal to 3 solves this potential issue for old input.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To provide a counter argument what if the old input is this:

4025 296 'lwtr' /
1001 /

I think providing a single ZA is more common (which is why it was the default).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we argue about this? It's a detail.

Anyway, in the case you bring up, the code will read it properly and reset nza to 1. Test 25 covers this behaviour and it passes with the current implementation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I didn't realize that it would read correctly (i.e., adding two extra zeros.) If that works, then we are good.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have to mimic the old implementation, in which these values were stored in three different variables and in which the second and third one were defaulted to zero (and that allows a user to add two zeros on the line). It's annoying but that's what it was before.

@coveralls
Copy link

coveralls commented Nov 7, 2019

Coverage Status

Coverage remained the same at ?% when pulling 79e80fa on fix/acer-iza into fb2e912 on master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants