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?

asked Nov 21 '18 at 19:19

Youjun Hu

538

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

  /

asked Nov 21 '18 at 19:19

Youjun Hu

538

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

  /

asked Nov 21 '18 at 19:19

Youjun Hu

538

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

  /

fortran

asked Nov 21 '18 at 19:19

Youjun Hu

538

asked Nov 21 '18 at 19:19

Youjun Hu

538

asked Nov 21 '18 at 19:19

Youjun Hu

538

asked Nov 21 '18 at 19:19

Youjun Hu

538

asked Nov 21 '18 at 19:19

Youjun Hu

538

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

francescalus

17.5k73456

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 /, 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

@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, 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

@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

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
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

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

Name

Required, but never shown

1 Answer
1

active

oldest

votes

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.

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.

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

francescalus

17.5k73456

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 /, 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

@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, 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

@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

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.

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.

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

francescalus

17.5k73456

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 /, 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

@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, 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

@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

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.

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.

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

francescalus

17.5k73456

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.

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.

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

francescalus

17.5k73456

answered Nov 21 '18 at 21:14

francescalus

17.5k73456

answered Nov 21 '18 at 21:14

francescalus

17.5k73456

answered Nov 21 '18 at 21:14

francescalus

17.5k73456

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 /, 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

@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, 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

@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

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 /, 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

@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, 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

@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

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

@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, 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, 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

draft saved

draft discarded

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.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

Search This Blog

Ufyukyu