- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Once you put a variable into a common, it is no longer a local variable. I don't see why you play tricks with EQUIVALENCE and don't just put "local" into the COMMON to be saved, since that's what you want. However, if you use this same common name in more than one routine, you'll be saving only one of the variables, which I suspect is the problem you're running into. Essentially, you need to list each of the "local" variables separately in a common that the program then saves and restores. There are no shortcuts to this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is your real problem that these local variables are not properly initialised on a restart? How are they initialised on a first run? Are initial values of zero assumed as was a bad assumption of some older code based on the fact that on some older compilers this just happened to be the case? As Steve says you need to fundamentally look at the code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>At certain time, the code will dump all common block data into this restart file. Later the code will read the restart file and try to continue the calculation from there.
Your save and restore points are not performed at arbitrary states of the application (NOT while you are n-levels down into a call tree in the middle of a calculation), rather they are likely performed in you main loop (e.g. time integration loop) after the time step calculations. When this is the case, then the temporary variables of the subroutines in the call tree need not be saved (but some of the loop control and temporaries of the main loop may need to be saved/restored).
Andrew's advice extends the other direction too.
program xxx ... if(restarting) then call loadRestartData() else ... ! code to load and initialize simulation endif ... do while(.not. Done) ... if(atSavePointInterval) call saveState() end do ... end program
What I mean is that the code in the LoadRestartData() may not initialize significant data that the ... ! code to load... does, and that data is require by the do while(.not. Done) loop.
As Steve says you need to fundamentally look at the code.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks a lot, Steve. Yes, it would be better to directly save the locals into a common block. The potential issue of doing is as you said, there are thousands of subroutines in this legacy code, and many local variables have the same name in different subroutines. If doing so, there is one subroutine to write and read all those local variables (now defined in common blocks) into a restart file, it could have issue of having identical local variable names present in different common blocks (defined for local variables). There is the problem I was trying to work around using EQUIVALENCE statement, which does not work as I thought from the testing results.
Would there be any work around to this dilemma? Thanks a lot!
Jim
Steve Lionel (Ret.) wrote:
Once you put a variable into a common, it is no longer a local variable. I don't see why you play tricks with EQUIVALENCE and don't just put "local" into the COMMON to be saved, since that's what you want. However, if you use this same common name in more than one routine, you'll be saving only one of the variables, which I suspect is the problem you're running into. Essentially, you need to list each of the "local" variables separately in a common that the program then saves and restores. There are no shortcuts to this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Why do you have to write all local variables into a restart file?
Let us call the part of the main program that has been executed before the restart file is written as 'A' and the rest of the program as 'B'.
Then, none of the local variables need to saved in those subroutines that are called only after restart, i.e., subroutines called from part B and not from part A. Similarly, there is no need to save and restore the local variables of those subroutines of part A that have not yet been called when the restart/restore point is reached.
In general, local variables need not be saved for those subroutines that are known to be called just once during a run of the program.
These considerations can help you to reduce the number of variables that need to be saved and restored.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, only if the local variables in the legacy code were properly used as "local". However, in the fact, there are many local variables in the legacy code should never be used as local, as shown in my sample code. The effort is trying to correct the mistake in the legacy code while minimize code changes due to QA requirements.
Thanks for your insights!
Jim
mecej4 wrote:
Why do you have to write all local variables into a restart file?
Let us call the part of the main program that has been executed before the restart file is written as 'A' and the rest of the program as 'B'.
Then, none of the local variables need to saved in those subroutines that are called only after restart, i.e., subroutines called from part B and not from part A. Similarly, there is no need to save and restore the local variables of those subroutines of part A that have not yet been called when the restart/restore point is reached.
In general, local variables need not be saved for those subroutines that are known to be called just once during a run of the program.
These considerations can help you to reduce the number of variables that need to be saved and restored.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, some local variables are not initialized during restart. The first run, all local variables should default to be 0 or false. As code calculation proceed, some local variables get calculated with different values, and these values must be saved in restart file in order to repeat the calculation as if it is run from time 0.
andrew_4619 wrote:
Is your real problem that these local variables are not properly initialised on a restart? How are they initialised on a first run? Are initial values of zero assumed as was a bad assumption of some older code based on the fact that on some older compilers this just happened to be the case? As Steve says you need to fundamentally look at the code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>The first run, all local variables should default to be 0 or false
That is an incorrect assumption. Observing it once at some time does not make it certain that 0 initialization is require by the language.
Jim Dempsey

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page