[Fortran] something very peculiar

[Matterwave]

Hello guys,

As, you probably know by now, I've been trying to run this piece of code for a while now. I finally got it to run and then I realized something very weird is happening!

So in my code, which simulates neutrino evolution, I have made 3 conditional statements in the evolution stage of the code, depending on a parameter that I defined in a module called params.

In my module called params there is a line:

integer, parameter::spinco=1

spinco should be a parameter defining if I want to run the simulation with or without a "spin-coherence term" in the Hamiltonian. spinco=0 means no spin-coherence, spinco=1 means majorana type spin-coherence, and spinco=2 means dirac type spin-coherence. (It's not important that you understand what this means, but just that spinco governs what kind of Hamiltonian I'm using).

In my main code there are lines like:

 if(spinco.eq.0) then
XXX
else if(spinco.eq.1) then
XXX
else if(spinco.eq.2) then
XXX
endif

Now, this part of the code is VERY IMPORTANT because this is the part of the code that actually evolves the wave function (the rest of the code is finding the Hamiltonian lol). Here's the weird part. I FORGOT to put the parameter spinco in my params.F90 file (meaning, I did not define it at all, there was no integer,parameter:: spinco line in the params file), and tried to run the code (only realizing I forgot this afterwards). The code ran! I didn't get any errors like "undefined variable 'spinco'" or anything like that! It went through several hundred loops before I stopped it, and the output looked normal! I am so perplexed by this. How can this code run if I didn't declare the parameter spinco?

This question is very important to me because the first "proof of concept" test I am running is to show that my code gives the same output as an unmodified set of code that has none of this "spin coherence" stuff in it if I set spinco=1 and set all the "majorana terms" in the Hamiltonian to 0. If I set all the "majorana terms" to 0, the problem SHOULD reduce to the spinco=0 case and I SHOULD get the same result as the old un-modified code. This should prove that my architecture is valid, and that I can proceed to the next phase.

But since WITHOUT DEFINING spinco AT ALL, the code ran AND seemed to give me the "correct" output, I am now not certain if my modifications to the code is actually doing anything at all...:(

Anyone have any insights into this?

 

[the_wolfman]

Are you using Implicit None?

If not FORTRAN will implicitly assume that Spinco is a real.

 

[gsal]

what he said...

...this is one of the first things you learn about Fortran...variables do not need to be declared and if so, variables with names starting with the letters I through N are implicitly INTEGER, otherwise they are REAL.

Oh, and hopefully, variables that were not declared will take on zero value...but I am not sure if this is guaranteed, it may depend on the compiler or compiler flags.

 

[SteamKing]

Hello guys,

As, you probably know by now, I've been trying to run this piece of code for a while now. I finally got it to run and then I realized something very weird is happening!

So in my code, which simulates neutrino evolution, I have made 3 conditional statements in the evolution stage of the code, depending on a parameter that I defined in a module called params.

In my module called params there is a line:

integer, parameter::spinco=1

spinco should be a parameter defining if I want to run the simulation with or without a "spin-coherence term" in the Hamiltonian. spinco=0 means no spin-coherence, spinco=1 means majorana type spin-coherence, and spinco=2 means dirac type spin-coherence. (It's not important that you understand what this means, but just that spinco governs what kind of Hamiltonian I'm using).

In my main code there are lines like:

 if(spinco.eq.0) then
XXX
else if(spinco.eq.1) then
XXX
else if(spinco.eq.2) then
XXX
endif

Now, this part of the code is VERY IMPORTANT because this is the part of the code that actually evolves the wave function (the rest of the code is finding the Hamiltonian lol). Here's the weird part. I FORGOT to put the parameter spinco in my params.F90 file (meaning, I did not define it at all, there was no integer,parameter:: spinco line in the params file), and tried to run the code (only realizing I forgot this afterwards). The code ran! I didn't get any errors like "undefined variable 'spinco'" or anything like that! It went through several hundred loops before I stopped it, and the output looked normal! I am so perplexed by this. How can this code run if I didn't declare the parameter spinco?

This question is very important to me because the first "proof of concept" test I am running is to show that my code gives the same output as an unmodified set of code that has none of this "spin coherence" stuff in it if I set spinco=1 and set all the "majorana terms" in the Hamiltonian to 0. If I set all the "majorana terms" to 0, the problem SHOULD reduce to the spinco=0 case and I SHOULD get the same result as the old un-modified code. This should prove that my architecture is valid, and that I can proceed to the next phase.

But since WITHOUT DEFINING spinco AT ALL, the code ran AND seemed to give me the "correct" output, I am now not certain if my modifications to the code is actually doing anything at all...:(

Anyone have any insights into this?

The Fortran PARAMETER statement is designed so that the programmer can specify a named constant value, something that is not supposed to change during the running of the program, like REAL PARAMETER PI :: 3.1415926.

Since you want to use the parameter SPINCO to select a certain type of calculation, you should make it a variable instead of a PARAMETER, which would allow you to change its value depending on other factors or make it an input.

 

[Matterwave]

The Fortran PARAMETER statement is designed so that the programmer can specify a named constant value, something that is not supposed to change during the running of the program, like REAL PARAMETER PI :: 3.1415926.

Since you want to use the parameter SPINCO to select a certain type of calculation, you should make it a variable instead of a PARAMETER, which would allow you to change its value depending on other factors or make it an input.

spinco will never be changed, and should not be changed, during a single run, so I think keeping it as a parameter is correct.

Also, I think my modifications did do something since now running the code I am getting no evolution of the wave function lol!.

 

[Matterwave]

Are you using Implicit None?

If not FORTRAN will implicitly assume that Spinco is a real.

I see, yes, the code is not written with implicit none. So I'm guessing spinco will be given some memory space and assigned some value based on whatever junk is in that space?

I have never been formally taught fortran, I sort of just picked it up as I go.

 

[SteamKing]

spinco will never be changed, and should not be changed, during a single run, so I think keeping it as a parameter is correct.

Also, I think my modifications did do something since now running the code I am getting no evolution of the wave function lol!.

If the SPINCO parameter is never to be changed, then why include all the conditional statements which depend on the value of SPINCO? This is where novice programmers create needless complexity in their code.

 

[Matterwave]

If the SPINCO parameter is never to be changed, then why include all the conditional statements which depend on the value of SPINCO? This is where novice programmers create needless complexity in their code.

Spinco might be needed to be changed for different runs of the code. I might run the code and try to simulate majorana neutrinos and choose spinco=1, and then run the code again to simulate dirac neutrinos and choose spinco=2. But within 1 iteration of the program, spinco should never change, because I either simulate majorana, or dirac, I can't simulate both.

Different conditions on spinco requires different evolution of the wave function; hence, why all the conditional statements.

This way I can change one parameter in params and run a wholly different simulation, instead of having to go back and rewrite the code every time.

 

[jtbell]

Spinco might be needed to be changed for different runs of the code.

Values specified in a PARAMETER statement are fixed at compilation time. Are you planning to re-compile the program every time you change the value of SPINCO? If not, then you should not make SPINCO a PARAMETER, but rather declare it as a normal variable.

 

[Matterwave]

Values specified in a PARAMETER statement are fixed at compilation time. Are you planning to re-compile the program every time you change the value of SPINCO? If not, then you should not make SPINCO a PARAMETER, but rather declare it as a normal variable.

I believe using makefile I can recompile just the necessary pieces of the code?

But right now I have indeed been recompiling at each run. Each run might take (when all is said and done) between 10 and 100 hours. Compiling takes <20 seconds. So it's not really a problem. I would rather keep it as a parameter to make sure I don't make a mistake and reassign a value to it during some other parts of the code.

 

[Mark44]

But right now I have indeed been recompiling at each run. Each run might take (when all is said and done) between 10 and 100 hours. Compiling takes <20 seconds. So it's not really a problem. I would rather keep it as a parameter to make sure I don't make a mistake and reassign a value to it during some other parts of the code.

Even though compilation time is very small in comparison to run time, it makes sense to me (and the others in this thread) to make it a variable. At the beginning of your main program you could present a simple interface to ask the user for the spinco value, and then take whatever action is appropriate after that. There should be no reason to change its value anywhere else in your code.

It seems silly to me to have to recompile code just because a single number changes, regardless of how little time the compiler takes. Furthermore, if at some point down the line you have the executable handy and you don't remember where all the source code is, a recompile might be a real inconvenience.

 

[Matterwave]

Even though compilation time is very small in comparison to run time, it makes sense to me (and the others in this thread) to make it a variable. At the beginning of your main program you could present a simple interface to ask the user for the spinco value, and then take whatever action is appropriate after that. There should be no reason to change its value anywhere else in your code.

It seems silly to me to have to recompile code just because a single number changes, regardless of how little time the compiler takes. Furthermore, if at some point down the line you have the executable handy and you don't remember where all the source code is, a recompile might be a real inconvenience.

If this were the overall philosophy of the code that I'm working on, then yeah, I might have gone this way with the coding, but really there are already a ton of other "parameters" that could theoretically be changed at every run-time including all the # of bins of energy and angles, and number of flavors you want to simulate, etc. All of those were written as parameters just like I have written spinco. Many of those need to be parameters because they must be determined at compile time since they give the sizes of arrays. And I can not be certain that in future edits of the code spinco will not be used in a similar way. Right now it is only used in conditional statements; but, I could certainly see some instances where I might use spinco as an integer in an array declaration or some such. I have not written the code to find the Hamiltonian matrix yet. There is no interface while running this code, you create the executable, you run the executable in the terminal, or on the supercomputer, and you wait for the code to finish so you can look at the output.

 

[Mark44]

If this were the overall philosophy of the code that I'm working on, then yeah, I might have gone this way with the coding, but really there are already a ton of other "parameters" that could theoretically be changed at every run-time including all the # of bins of energy and angles, and number of flavors you want to simulate, etc. All of those were written as parameters just like I have written spinco. Many of those need to be parameters because they must be determined at compile time since they give the sizes of arrays.

Which is reasonable justification for making them parameters.

And I can not be certain that in future edits of the code spinco will not be used in a similar way. Right now it is only used in conditional statements; but, I could certainly see some instances where I might use spinco as an integer in an array declaration or some such. I have not written the code to find the Hamiltonian matrix yet. There is no interface while running this code, you create the executable, you run the executable in the terminal, or on the supercomputer, and you wait for the code to finish so you can look at the output.

So even though you haven't written the code to find the Hamiltonian yet, it sounds like that's something you will be doing down the line. I'm not talking about anything fancy for the interface - probably two lines of code, a WRITE or PRINT statement for the prompt on the terminal, and a READ statement for the input.

You've asked for advice from this group, and between us all we have many, many decades of writing code in literally dozens of programming languages. If we are unanimous in advising for or against something, you should really think hard about going against that advice.

 

[Matterwave]

\

Which is reasonable justification for making them parameters.

So even though you haven't written the code to find the Hamiltonian yet, it sounds like that's something you will be doing down the line. I'm not talking about anything fancy for the interface - probably two lines of code, a WRITE or PRINT statement for the prompt on the terminal, and a READ statement for the input.

You've asked for advice from this group, and between us all we have many, many decades of writing code in literally dozens of programming languages. If we are unanimous in advising for or against something, you should really think hard about going against that advice.

Ok, when I finish writing the code, if at that time spinco remains inside conditionals only, and does not find itself into any array size declarations, I'll remove the parameter tag from it and write a few lines to take input and determine it from the terminal. Thanks for the advice.

 

[DrClaude]

Didn't I tell you before?

<feigned indignation> Then I won't be helping you anymore! I refuse to debug any code with implicit declarations. </feigned indignation>

:D

 

[the_wolfman]

I see, yes, the code is not written with implicit none. So I'm guessing spinco will be given some memory space and assigned some value based on whatever junk is in that space?

I'm not sure what your code is doing, but it probably depends on your compiler and what compiler flags you are using. The assigned value might be based on whatever was previously in memory, or your compiler might automatically assign it a value. I don't know.

Use IMPLICIT NONE!

This is a huge deal. The rest of the discussion is noise at this point. With out implicit none you should not believe any of the results your code is generating! NONE!

Implicit delcartions can break your code in too many ways.

 

[Matterwave]

Didn't I tell you before?

:D

Yes, you were right! I am not used to not having "implicit none" either.

 

[Matterwave]

I'm not sure what your code is doing, but it probably depends on your compiler and what compiler flags you are using. The assigned value might be based on whatever was previously in memory, or your compiler might automatically assign it a value. I don't know.

Use IMPLICIT NONE!

This is a huge deal. The rest of the discussion is noise at this point. With out implicit none you should not believe any of the results your code is generating! NONE!

Implicit delcartions can break your code in too many ways.

Yeah, I might go on and try to get that implemented. The code has the declaration "implicit real(kind=reel8) (a-h,o-z)" instead, I'm not sure what's up with that.

 

[Mark44]

Yeah, I might go on and try to get that implemented. The code has the declaration "implicit real(kind=reel8) (a-h,o-z)" instead, I'm not sure what's up with that.

I seem to remember that you asked about this before in another thread. This statement means that all variables whose names begin with a through h and o through z are 8-byte reals.

DrClaude had this to say about these implicit statements in this thread - https://www.physicsforums.com/threads/fortran-help-figuring-out-zheev.769647/:

Annd please please please remove that eyesore

implicit real(kind=reel8) (a-h,o-z)

and replace it by

implicit none

 

[Matterwave]

I seem to remember that you asked about this before in another thread. This statement means that all variables whose names begin with a through h and o through z are 8-byte reals.

DrClaude had this to say about these implicit statements in this thread - https://www.physicsforums.com/threads/fortran-help-figuring-out-zheev.769647/:

Ah ok. In that case, I would have to replace it, and then declare all the letters used in all the loops in this program. I'll...get around to that...hopefully.

 

[the_wolfman]

Ah ok. In that case, I would have to replace it, and then declare all the letters used in all the loops in this program. I'll...get around to that...hopefully.

Are you the only one using the code or are there other developers?

If you're the only one then switch to implict none. If there are other people working on this code then you should have a talk with them before switching. When part of a team, never suddenly switching established conventions.

Either way its important that you under implicit declarations. If you're going to continue to use them in your code, then you need to find effective ways to debug your code.

 

[Matterwave]

Are you the only one using the code or are there other developers?

If you're the only one then switch to implict none. If there are other people working on this code then you should have a talk with them before switching. When part of a team, never suddenly switching established conventions.

Either way its important that you under implicit declarations. If you're going to continue to use them in your code, then you need to find effective ways to debug your code.

Is there a way to keep the "implicit real 'a-h' etc." stuff but then declare all other variables as non-implicit? I am the only one working on my copy of this code at the moment. I am not the one who wrote the majority of this code. All I am doing is adding a module to make it handle some extra simulations. I don't work as part of a team at the moment.

 

[Mark44]

Is there a way to keep the "implicit real 'a-h' etc." stuff but then declare all other variables as non-implicit?

You can do this: (per Oracle F77 docs at http://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vn9v/index.html)

IMPLICIT INTEGER (A-Z)
IMPLICIT REAL (A-C)
C = 1.5E8
D = 9
In the above example, D through Z implies INTEGER, and A through C implies REAL.

I am the only one working on my copy of this code at the moment. I am not the one who wrote the majority of this code. All I am doing is adding a module to make it handle some extra simulations. I don't work as part of a team at the moment.

 

[FactChecker]

Omitting "implicit none" has two dangers -- one you can mitigate by getting used to the i-n defaults. The other danger is harder to eliminate. A typo in a variable name goes undetected. It's very hard to spot a wrong character in the middle of a variable name, Then the program will compile and run with that variable = 0 and no one spots the error for a long time. I used to run a script that went through compiler output lists of variables checking for variables that only appeared only once. They were typos.