-
Notifications
You must be signed in to change notification settings - Fork 7
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
pfscale 2.3rev5d failure with certain profiles #31
Comments
Found the source code of version 2.3.2 if you want it (also earlier ones). But the differences between
Of course, like you mentioned, no information about this 10 upper limit. Did you try to replace 10 by, for example 20, to see if the result makes sense? |
Yes I did try replacing 10 by 20 and the profile gets produced is fine, it has an R1 value of 17.6187992 when the one produced by pfscale 2.3 rev 2 has an R1 value of 17.6187973 - not much of a difference. |
Did you see some differences with pfscale 2.3 rev 2 I missed? |
The issue regards the writing of the R1 and R2 values.
The part of the code concerns with the problem is wrprf.f lines 262-26 .
The problem manifests itself with the following command:
With the output reporting:
[test_score.txt] [test_prf.txt]
In this peculiar case, the problem concerns the writing of the R1 value (
RNOP(I2,I1)
in the code) which is 17.6187992 (If printed with 7 digits to the right of the decimal point)Rewriting the IF/ELSE clause of wrprf.f lines 262-26 in pseudo code:
A few comments/interrogations:
ELSE
category.F10.7
means 10 characters of which 7 digits to the right of the decimal point.Write(CHRP(I2),*)
seems to expect either a string or an integer.** What is the expected formatting of data not falling in the
IF
category, i.e. for R1 <= 0.0001 or R1 > 10?** Why is there an upper limit of 10 in the
IF
clause? Without this limit R1 would fall in theIF
clause.The text was updated successfully, but these errors were encountered: