How to raise runtime error when a namelist variable is missing in an input namelist file?
An example code is as follows:
program main
implicit none
integer :: ufile
real :: a, b, c
namelist /my_nlt/ a, b, c
open(newunit=ufile,file='my_nlt.txt')
read(ufile,my_nlt)
close(ufile)
write(*,my_nlt)
end program main
And the input file my_nlt.txt contains:
&my_nlt
a=1.0
b=2.0
/
Here the variable c is missing in the input file.
Running the code compiled by gfortran gives no warnning/error. I am wondering whether there is a compiler option that can be used to raise an error/warning when encountering this situation?
fortran
asked Nov 21 '18 at 19:19
Youjun HuYoujun Hu
518
add a comment |
An example code is as follows:
program main
implicit none
integer :: ufile
real :: a, b, c
namelist /my_nlt/ a, b, c
open(newunit=ufile,file='my_nlt.txt')
read(ufile,my_nlt)
close(ufile)
write(*,my_nlt)
end program main
And the input file my_nlt.txt contains:
&my_nlt
a=1.0
b=2.0
/
Here the variable c is missing in the input file.
Running the code compiled by gfortran gives no warnning/error. I am wondering whether there is a compiler option that can be used to raise an error/warning when encountering this situation?
fortran
asked Nov 21 '18 at 19:19
Youjun HuYoujun Hu
518
add a comment |
An example code is as follows:
program main
implicit none
integer :: ufile
real :: a, b, c
namelist /my_nlt/ a, b, c
open(newunit=ufile,file='my_nlt.txt')
read(ufile,my_nlt)
close(ufile)
write(*,my_nlt)
end program main
And the input file my_nlt.txt contains:
&my_nlt
a=1.0
b=2.0
/
Here the variable c is missing in the input file.
Running the code compiled by gfortran gives no warnning/error. I am wondering whether there is a compiler option that can be used to raise an error/warning when encountering this situation?
fortran
asked Nov 21 '18 at 19:19
Youjun HuYoujun Hu
518
An example code is as follows:
program main
implicit none
integer :: ufile
real :: a, b, c
namelist /my_nlt/ a, b, c
open(newunit=ufile,file='my_nlt.txt')
read(ufile,my_nlt)
close(ufile)
write(*,my_nlt)
end program main
And the input file my_nlt.txt contains:
&my_nlt
a=1.0
b=2.0
/
Here the variable c is missing in the input file.
Running the code compiled by gfortran gives no warnning/error. I am wondering whether there is a compiler option that can be used to raise an error/warning when encountering this situation?
fortran
fortran
asked Nov 21 '18 at 19:19
Youjun HuYoujun Hu
518
asked Nov 21 '18 at 19:19
Youjun HuYoujun Hu
518
asked Nov 21 '18 at 19:19
Youjun HuYoujun Hu
518
asked Nov 21 '18 at 19:19
Youjun HuYoujun Hu
518
asked Nov 21 '18 at 19:19
Youjun HuYoujun Hu
518
518
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
I am not aware of such an option for gfortran (or any other Fortran compiler). I would also strongly recommend not relying on such an option should one be found.
Namelist formatting exists to give a certain simplicity and flexibility of input to specific objects. Desiring a warning with a namelist read not updating all variables is perhaps trying to use the tool inappropriately.
For the program and input of the question, the expected runtime behaviour is for a and b to be defined with the values stated, and for c to be undefined. Instead, we could define the three variables with a value prior to the read and see whether they are updated by the read:
real, parameter :: SENTINEL=HUGE(0.)
real :: a=SENTINEL, b=SENTINEL, c=SENTINEL
namelist /my_nlt/ a, b, c
open(newunit=ufile,file='my_nlt.txt')
read(ufile,my_nlt)
if (a==SENTINEL.or.b==SENTINEL.or.c==SENTINEL) ERROR STOP
Here SENTINEL would be a value undesired for the variables or unexpected in the input. A variable not included in a namelist record retains its value prior to the read.
This isn't the same thing as certainly not appearing (especially where there may be no out-of-range input value) but if you want to check that then you'll have to parse the input file manually. The structure of such a namelist file is well defined.
As a final consideration, is the variable c "present" in the following namelist input record?
&my_nlt a=1., b=2., c=1* /
answered Nov 21 '18 at 21:14
francescalusfrancescalus
17.8k73457
1
Adding to @francescalus' excellent answer, a NAMELIST read where a variable is not named leaves the variable in its previous definition status. I'll note that you can't even rely on a compiler's uninitialized variable checking to detect this.
– Steve Lionel
Nov 22 '18 at 0:36
If the input file looks like&my_nlt a=1.0,b=2.0, c=2+1 /,cstill gets a value without error (tested using gfortran), but the value is not as we expected. To just test whether a variable presents, maybe the safest way is to parse the input file manually.
– Youjun Hu
Nov 22 '18 at 6:09
1
@YoujunHu, my comment about using the tool "inappropriately" relates to how namelist input is designed not to affect variables which don't feature in the input record (and may appear in any order, or incompletely), which is in stark contrast to the other form of formatted input. Think of it as a facility like command line arguments: the user expects to be able to give just a selection of values on the command line, perhaps leaving others as "default values" or unspecified.
– francescalus
Nov 22 '18 at 16:15
1
@YoujunHu,chas a well-defined value from the namelist record&my_nlt a=1.0,b=2.0, c=2+1 /. That value is20.. [If you don't understand why, then that could make a good question.]
– francescalus
Nov 22 '18 at 16:21
1
@YoujunHu, it's 20 because2+1as input field is interpreted as 2 with exponent 1 (2×10^1).
– francescalus
Nov 22 '18 at 17:59
|
show 2 more comments
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53419146%2fhow-to-raise-runtime-error-when-a-namelist-variable-is-missing-in-an-input-namel%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I am not aware of such an option for gfortran (or any other Fortran compiler). I would also strongly recommend not relying on such an option should one be found.
Namelist formatting exists to give a certain simplicity and flexibility of input to specific objects. Desiring a warning with a namelist read not updating all variables is perhaps trying to use the tool inappropriately.
For the program and input of the question, the expected runtime behaviour is for a and b to be defined with the values stated, and for c to be undefined. Instead, we could define the three variables with a value prior to the read and see whether they are updated by the read:
real, parameter :: SENTINEL=HUGE(0.)
real :: a=SENTINEL, b=SENTINEL, c=SENTINEL
namelist /my_nlt/ a, b, c
open(newunit=ufile,file='my_nlt.txt')
read(ufile,my_nlt)
if (a==SENTINEL.or.b==SENTINEL.or.c==SENTINEL) ERROR STOP
Here SENTINEL would be a value undesired for the variables or unexpected in the input. A variable not included in a namelist record retains its value prior to the read.
This isn't the same thing as certainly not appearing (especially where there may be no out-of-range input value) but if you want to check that then you'll have to parse the input file manually. The structure of such a namelist file is well defined.
As a final consideration, is the variable c "present" in the following namelist input record?
&my_nlt a=1., b=2., c=1* /
answered Nov 21 '18 at 21:14
francescalusfrancescalus
17.8k73457
1
Adding to @francescalus' excellent answer, a NAMELIST read where a variable is not named leaves the variable in its previous definition status. I'll note that you can't even rely on a compiler's uninitialized variable checking to detect this.
– Steve Lionel
Nov 22 '18 at 0:36
If the input file looks like&my_nlt a=1.0,b=2.0, c=2+1 /,cstill gets a value without error (tested using gfortran), but the value is not as we expected. To just test whether a variable presents, maybe the safest way is to parse the input file manually.
– Youjun Hu
Nov 22 '18 at 6:09
1
@YoujunHu, my comment about using the tool "inappropriately" relates to how namelist input is designed not to affect variables which don't feature in the input record (and may appear in any order, or incompletely), which is in stark contrast to the other form of formatted input. Think of it as a facility like command line arguments: the user expects to be able to give just a selection of values on the command line, perhaps leaving others as "default values" or unspecified.
– francescalus
Nov 22 '18 at 16:15
1
@YoujunHu,chas a well-defined value from the namelist record&my_nlt a=1.0,b=2.0, c=2+1 /. That value is20.. [If you don't understand why, then that could make a good question.]
– francescalus
Nov 22 '18 at 16:21
1
@YoujunHu, it's 20 because2+1as input field is interpreted as 2 with exponent 1 (2×10^1).
– francescalus
Nov 22 '18 at 17:59
|
show 2 more comments
I am not aware of such an option for gfortran (or any other Fortran compiler). I would also strongly recommend not relying on such an option should one be found.
Namelist formatting exists to give a certain simplicity and flexibility of input to specific objects. Desiring a warning with a namelist read not updating all variables is perhaps trying to use the tool inappropriately.
For the program and input of the question, the expected runtime behaviour is for a and b to be defined with the values stated, and for c to be undefined. Instead, we could define the three variables with a value prior to the read and see whether they are updated by the read:
real, parameter :: SENTINEL=HUGE(0.)
real :: a=SENTINEL, b=SENTINEL, c=SENTINEL
namelist /my_nlt/ a, b, c
open(newunit=ufile,file='my_nlt.txt')
read(ufile,my_nlt)
if (a==SENTINEL.or.b==SENTINEL.or.c==SENTINEL) ERROR STOP
Here SENTINEL would be a value undesired for the variables or unexpected in the input. A variable not included in a namelist record retains its value prior to the read.
This isn't the same thing as certainly not appearing (especially where there may be no out-of-range input value) but if you want to check that then you'll have to parse the input file manually. The structure of such a namelist file is well defined.
As a final consideration, is the variable c "present" in the following namelist input record?
&my_nlt a=1., b=2., c=1* /
answered Nov 21 '18 at 21:14
francescalusfrancescalus
17.8k73457
1
Adding to @francescalus' excellent answer, a NAMELIST read where a variable is not named leaves the variable in its previous definition status. I'll note that you can't even rely on a compiler's uninitialized variable checking to detect this.
– Steve Lionel
Nov 22 '18 at 0:36
If the input file looks like&my_nlt a=1.0,b=2.0, c=2+1 /,cstill gets a value without error (tested using gfortran), but the value is not as we expected. To just test whether a variable presents, maybe the safest way is to parse the input file manually.
– Youjun Hu
Nov 22 '18 at 6:09
1
@YoujunHu, my comment about using the tool "inappropriately" relates to how namelist input is designed not to affect variables which don't feature in the input record (and may appear in any order, or incompletely), which is in stark contrast to the other form of formatted input. Think of it as a facility like command line arguments: the user expects to be able to give just a selection of values on the command line, perhaps leaving others as "default values" or unspecified.
– francescalus
Nov 22 '18 at 16:15
1
@YoujunHu,chas a well-defined value from the namelist record&my_nlt a=1.0,b=2.0, c=2+1 /. That value is20.. [If you don't understand why, then that could make a good question.]
– francescalus
Nov 22 '18 at 16:21
1
@YoujunHu, it's 20 because2+1as input field is interpreted as 2 with exponent 1 (2×10^1).
– francescalus
Nov 22 '18 at 17:59
|
show 2 more comments
I am not aware of such an option for gfortran (or any other Fortran compiler). I would also strongly recommend not relying on such an option should one be found.
Namelist formatting exists to give a certain simplicity and flexibility of input to specific objects. Desiring a warning with a namelist read not updating all variables is perhaps trying to use the tool inappropriately.
For the program and input of the question, the expected runtime behaviour is for a and b to be defined with the values stated, and for c to be undefined. Instead, we could define the three variables with a value prior to the read and see whether they are updated by the read:
real, parameter :: SENTINEL=HUGE(0.)
real :: a=SENTINEL, b=SENTINEL, c=SENTINEL
namelist /my_nlt/ a, b, c
open(newunit=ufile,file='my_nlt.txt')
read(ufile,my_nlt)
if (a==SENTINEL.or.b==SENTINEL.or.c==SENTINEL) ERROR STOP
Here SENTINEL would be a value undesired for the variables or unexpected in the input. A variable not included in a namelist record retains its value prior to the read.
This isn't the same thing as certainly not appearing (especially where there may be no out-of-range input value) but if you want to check that then you'll have to parse the input file manually. The structure of such a namelist file is well defined.
As a final consideration, is the variable c "present" in the following namelist input record?
&my_nlt a=1., b=2., c=1* /
answered Nov 21 '18 at 21:14
francescalusfrancescalus
17.8k73457
I am not aware of such an option for gfortran (or any other Fortran compiler). I would also strongly recommend not relying on such an option should one be found.
Namelist formatting exists to give a certain simplicity and flexibility of input to specific objects. Desiring a warning with a namelist read not updating all variables is perhaps trying to use the tool inappropriately.
For the program and input of the question, the expected runtime behaviour is for a and b to be defined with the values stated, and for c to be undefined. Instead, we could define the three variables with a value prior to the read and see whether they are updated by the read:
real, parameter :: SENTINEL=HUGE(0.)
real :: a=SENTINEL, b=SENTINEL, c=SENTINEL
namelist /my_nlt/ a, b, c
open(newunit=ufile,file='my_nlt.txt')
read(ufile,my_nlt)
if (a==SENTINEL.or.b==SENTINEL.or.c==SENTINEL) ERROR STOP
Here SENTINEL would be a value undesired for the variables or unexpected in the input. A variable not included in a namelist record retains its value prior to the read.
This isn't the same thing as certainly not appearing (especially where there may be no out-of-range input value) but if you want to check that then you'll have to parse the input file manually. The structure of such a namelist file is well defined.
As a final consideration, is the variable c "present" in the following namelist input record?
&my_nlt a=1., b=2., c=1* /
answered Nov 21 '18 at 21:14
francescalusfrancescalus
17.8k73457
answered Nov 21 '18 at 21:14
francescalusfrancescalus
17.8k73457
answered Nov 21 '18 at 21:14
francescalusfrancescalus
17.8k73457
answered Nov 21 '18 at 21:14
francescalusfrancescalus
17.8k73457
17.8k73457
1
Adding to @francescalus' excellent answer, a NAMELIST read where a variable is not named leaves the variable in its previous definition status. I'll note that you can't even rely on a compiler's uninitialized variable checking to detect this.
– Steve Lionel
Nov 22 '18 at 0:36
If the input file looks like&my_nlt a=1.0,b=2.0, c=2+1 /,cstill gets a value without error (tested using gfortran), but the value is not as we expected. To just test whether a variable presents, maybe the safest way is to parse the input file manually.
– Youjun Hu
Nov 22 '18 at 6:09
1
@YoujunHu, my comment about using the tool "inappropriately" relates to how namelist input is designed not to affect variables which don't feature in the input record (and may appear in any order, or incompletely), which is in stark contrast to the other form of formatted input. Think of it as a facility like command line arguments: the user expects to be able to give just a selection of values on the command line, perhaps leaving others as "default values" or unspecified.
– francescalus
Nov 22 '18 at 16:15
1
@YoujunHu,chas a well-defined value from the namelist record&my_nlt a=1.0,b=2.0, c=2+1 /. That value is20.. [If you don't understand why, then that could make a good question.]
– francescalus
Nov 22 '18 at 16:21
1
@YoujunHu, it's 20 because2+1as input field is interpreted as 2 with exponent 1 (2×10^1).
– francescalus
Nov 22 '18 at 17:59
|
show 2 more comments
1
Adding to @francescalus' excellent answer, a NAMELIST read where a variable is not named leaves the variable in its previous definition status. I'll note that you can't even rely on a compiler's uninitialized variable checking to detect this.
– Steve Lionel
Nov 22 '18 at 0:36
If the input file looks like&my_nlt a=1.0,b=2.0, c=2+1 /,cstill gets a value without error (tested using gfortran), but the value is not as we expected. To just test whether a variable presents, maybe the safest way is to parse the input file manually.
– Youjun Hu
Nov 22 '18 at 6:09
1
@YoujunHu, my comment about using the tool "inappropriately" relates to how namelist input is designed not to affect variables which don't feature in the input record (and may appear in any order, or incompletely), which is in stark contrast to the other form of formatted input. Think of it as a facility like command line arguments: the user expects to be able to give just a selection of values on the command line, perhaps leaving others as "default values" or unspecified.
– francescalus
Nov 22 '18 at 16:15
1
@YoujunHu,chas a well-defined value from the namelist record&my_nlt a=1.0,b=2.0, c=2+1 /. That value is20.. [If you don't understand why, then that could make a good question.]
– francescalus
Nov 22 '18 at 16:21
1
@YoujunHu, it's 20 because2+1as input field is interpreted as 2 with exponent 1 (2×10^1).
– francescalus
Nov 22 '18 at 17:59
1
1
Adding to @francescalus' excellent answer, a NAMELIST read where a variable is not named leaves the variable in its previous definition status. I'll note that you can't even rely on a compiler's uninitialized variable checking to detect this.
– Steve Lionel
Nov 22 '18 at 0:36
Adding to @francescalus' excellent answer, a NAMELIST read where a variable is not named leaves the variable in its previous definition status. I'll note that you can't even rely on a compiler's uninitialized variable checking to detect this.
– Steve Lionel
Nov 22 '18 at 0:36
If the input file looks like
&my_nlt a=1.0,b=2.0, c=2+1 /, c still gets a value without error (tested using gfortran), but the value is not as we expected. To just test whether a variable presents, maybe the safest way is to parse the input file manually.– Youjun Hu
Nov 22 '18 at 6:09
If the input file looks like
&my_nlt a=1.0,b=2.0, c=2+1 /, c still gets a value without error (tested using gfortran), but the value is not as we expected. To just test whether a variable presents, maybe the safest way is to parse the input file manually.– Youjun Hu
Nov 22 '18 at 6:09
1
1
@YoujunHu, my comment about using the tool "inappropriately" relates to how namelist input is designed not to affect variables which don't feature in the input record (and may appear in any order, or incompletely), which is in stark contrast to the other form of formatted input. Think of it as a facility like command line arguments: the user expects to be able to give just a selection of values on the command line, perhaps leaving others as "default values" or unspecified.
– francescalus
Nov 22 '18 at 16:15
@YoujunHu, my comment about using the tool "inappropriately" relates to how namelist input is designed not to affect variables which don't feature in the input record (and may appear in any order, or incompletely), which is in stark contrast to the other form of formatted input. Think of it as a facility like command line arguments: the user expects to be able to give just a selection of values on the command line, perhaps leaving others as "default values" or unspecified.
– francescalus
Nov 22 '18 at 16:15
1
1
@YoujunHu,
c has a well-defined value from the namelist record &my_nlt a=1.0,b=2.0, c=2+1 /. That value is 20.. [If you don't understand why, then that could make a good question.]– francescalus
Nov 22 '18 at 16:21
@YoujunHu,
c has a well-defined value from the namelist record &my_nlt a=1.0,b=2.0, c=2+1 /. That value is 20.. [If you don't understand why, then that could make a good question.]– francescalus
Nov 22 '18 at 16:21
1
1
@YoujunHu, it's 20 because
2+1 as input field is interpreted as 2 with exponent 1 (2×10^1).– francescalus
Nov 22 '18 at 17:59
@YoujunHu, it's 20 because
2+1 as input field is interpreted as 2 with exponent 1 (2×10^1).– francescalus
Nov 22 '18 at 17:59
|
show 2 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53419146%2fhow-to-raise-runtime-error-when-a-namelist-variable-is-missing-in-an-input-namel%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
