




Fortran Programming Language









Neq Max Limit
I'm trying to add a new variable to my code so that my neq needs to go from neq = 34 to neq = 35. Doing this keeps my code from ever stopping. I've made sure that no other changes are causing the issue. Is there a max. neq I can use? I suppose the problem could be the format, but my attempts to change it have been fruitless. I'm sorry for this open ended question. I was just hoping for an easy answer since I can't figure out how to fix it. Thanks, Hos
You should show part of your code. neq SEEMS to be the name of an integer variable used by you, which in most Fortran compilers can be from 1 to 4294967296, but we reserve 1 of the 32 bits for a sign and so from 2147483648 to +2147483647. So if 34 to 35 is not working the problem is somewhere else. Showing the area of code that uses neq (and the earlier definition of what neq IS will get you better help. On May 25, 8:54 am, Hosley <kbro@gmail.com> wrote:+
> I'm trying to add a new variable to my code so that my neq needs to go > from neq = 34 to neq = 35. Doing this keeps my code from ever > stopping. I've made sure that no other changes are causing the issue. > Is there a max. neq I can use? I suppose the problem could be the > format, but my attempts to change it have been fruitless. > I'm sorry for this open ended question. I was just hoping for an easy > answer since I can't figure out how to fix it. > Thanks, > Hos
On May 24, 6:54 pm, Hosley <kbro@gmail.com> wrote: > I'm trying to add a new variable to my code so that my neq needs to go > from neq = 34 to neq = 35.
I am just guessing that neq stands for "number of equations". Does this mean you have a MODEL with 34 equations and you want to add one more? > Doing this keeps my code from ever > stopping. I've made sure that no other changes are causing the issue. > Is there a max. neq I can use?
1. Are you calling a subroutine package with such a limit? 2. More likely, you are passing incorrect arguments to a subroutine. One may be the array size and another an array. For example: DIMENSION FOO(34) NEQ=35 CALL FUBAR(NEQ,FOO....) > I suppose the problem could be the > format, but my attempts to change it have been fruitless. > I'm sorry for this open ended question. I was just hoping for an easy > answer since I can't figure out how to fix it.
Please provide more details, including some of your code.
On May 24, 7:25 pm, e p chandler <e@juno.com> wrote:
> On May 24, 6:54 pm, Hosley <kbro @gmail.com> wrote: > > I'm trying to add a new variable to my code so that my neq needs to go > > from neq = 34 to neq = 35. > I am just guessing that neq stands for "number of equations". Does > this mean you have a MODEL with 34 equations and you want to add one > more? > > Doing this keeps my code from ever > > stopping. I've made sure that no other changes are causing the issue. > > Is there a max. neq I can use? > 1. Are you calling a subroutine package with such a limit? > 2. More likely, you are passing incorrect arguments to a subroutine. > One may be the array size and another an array. For example: > DIMENSION FOO(34) > NEQ=35 > CALL FUBAR(NEQ,FOO....) > > I suppose the problem could be the > > format, but my attempts to change it have been fruitless. > > I'm sorry for this open ended question. I was just hoping for an easy > > answer since I can't figure out how to fix it. > Please provide more details, including some of your code.
I call on two subroutines here is the beginning for the main routine: implicit double precision (ah,oz) parameter(neq=35,nflux=25,nstepmax=10000) dimension y(neq),dy(neq) dimension flux(nflux) c Initialize variable from restart file irestart = 1 if (irestart.eq.1) then open (unit=20,file='restart.init') read (20,*) (y(k),k=1,neq) close (unit=20) endif do k=1,neq dy(k) = 0.0 enddo do k=1,nflux flux(k) = 0.0 enddo t = 0.0 ! time (ms) timend = 200.0 c Start integration time loop 2 do 20 j=1,nstepmax c write concentration starting with t=0 write (8,300) t,(y(k),k=1,5) write (9,300) t,(y(k),k=6,10) write (10,300) t,(y(k),k=11,15) write (11,300) t,(y(k),k=16,20) write (12,300) t,(y(k),k=21,25) write (13,300) t,(y(k),k=26,30) write (14,300) t,(y(k),k=31,35) do 10 i=1,1000 t = t + dt call rk4am(y,t,dy,dt,etol,emintol,neq,flux,nflux) The 1st subroutine (rk4am) starts as follows: subroutine rk4am(y,t,dy,dt,etol,emintol,neq,flux,nflux) implicit double precision (ah,oz) dimension y(neq),dy(neq) dimension ak1(neq),ak2(neq),ak3(neq),ak4(neq),ak5(neq) dimension z4(neq),z5(neq) dimension flux(nflux) The 2nd subroutine (called later) starts: subroutine fcn(y,t,dy,dt,neq,flux,nflux) implicit double precision (ah,oz) dimension dy(neq),y(neq) dimension flux(nflux) Later in the main routine I have the following format commands: 300 format(30(1x,1pe12.5)) 310 format(6(1x,1pe12.5)) Please let me know if I sent this in a wrong way. Thanks again, Hos
On May 24, 10:31 pm, Hosley <kbro@gmail.com> wrote:
> On May 24, 7:25 pm, e p chandler <e @juno.com> wrote: > > On May 24, 6:54 pm, Hosley <kbro@gmail.com> wrote: > > > I'm trying to add a new variable to my code so that my neq needs to go > > > from neq = 34 to neq = 35. > > I am just guessing that neq stands for "number of equations". Does > > this mean you have a MODEL with 34 equations and you want to add one > > more? > > > Doing this keeps my code from ever > > > stopping. I've made sure that no other changes are causing the issue. > > > Is there a max. neq I can use? > > 1. Are you calling a subroutine package with such a limit? > > 2. More likely, you are passing incorrect arguments to a subroutine. > > One may be the array size and another an array. For example: > > DIMENSION FOO(34) > > NEQ=35 > > CALL FUBAR(NEQ,FOO....) > > > I suppose the problem could be the > > > format, but my attempts to change it have been fruitless. > > > I'm sorry for this open ended question. I was just hoping for an easy > > > answer since I can't figure out how to fix it. > > Please provide more details, including some of your code. > I call on two subroutines here is the beginning for the main routine: > implicit double precision (ah,oz) > parameter(neq=35,nflux=25,nstepmax=10000) > dimension y(neq),dy(neq) > dimension flux(nflux) > c Initialize variable from restart file > irestart = 1 > if (irestart.eq.1) then > open (unit=20,file='restart.init') > read (20,*) (y(k),k=1,neq) > close (unit=20) > endif > do k=1,neq > dy(k) = 0.0 > enddo > do k=1,nflux > flux(k) = 0.0 > enddo > t = 0.0 ! time (ms) > timend = 200.0 > c Start integration time loop > 2 do 20 j=1,nstepmax > c write concentration starting with t=0 > write (8,300) t,(y(k),k=1,5) > write (9,300) t,(y(k),k=6,10) > write (10,300) t,(y(k),k=11,15) > write (11,300) t,(y(k),k=16,20) > write (12,300) t,(y(k),k=21,25) > write (13,300) t,(y(k),k=26,30) > write (14,300) t,(y(k),k=31,35) > do 10 i=1,1000 > t = t + dt > call rk4am(y,t,dy,dt,etol,emintol,neq,flux,nflux) > The 1st subroutine (rk4am) starts as follows: > subroutine rk4am(y,t,dy,dt,etol,emintol,neq,flux,nflux) > implicit double precision (ah,oz) > dimension y(neq),dy(neq) > dimension ak1(neq),ak2(neq),ak3(neq),ak4(neq),ak5(neq) > dimension z4(neq),z5(neq) > dimension flux(nflux) > The 2nd subroutine (called later) starts: > subroutine fcn(y,t,dy,dt,neq,flux,nflux) > implicit double precision (ah,oz) > dimension dy(neq),y(neq) > dimension flux(nflux) > Later in the main routine I have the following format commands: > 300 format(30(1x,1pe12.5)) > 310 format(6(1x,1pe12.5)) > Please let me know if I sent this in a wrong way. > Thanks again, > Hos
I do not see anything obviously wrong with the interface between your main program and your first subroutine. If things are passed through to the second subroutine from the first, then that is probably not a problem. Nor do the FORMAT statement appear to cause trouble. But I do see some variables that have not been given an initial value dt, etol and emintol Perhaps these have been assigned values but you have left the code out of your listing here? At this point I can not suggest anything but general debugging principles. Of course unset variables and array accesses outof bounds are suspects. That the program fails when you increase the size of an array suggests that your are overwriting something that was not touched before. Perhaps the program no longer converges? One old technique that is still good is the diagnostic PRINT statement. Adding something like PRINT *,i at the top of the outer loop may tell you if the program is making any progress. (or PRINT *,j at the top of the inner loop, etc.) Other readers here may have more ideas. Feel free to email me your source code and data if you would like. Good luck.  email: epc8 at juno dot com
Hosley wrote:
(snip) > c write concentration starting with t=0 > write (8,300) t,(y(k),k=1,5) > write (9,300) t,(y(k),k=6,10) > write (10,300) t,(y(k),k=11,15) > write (11,300) t,(y(k),k=16,20) > write (12,300) t,(y(k),k=21,25) > write (13,300) t,(y(k),k=26,30) > write (14,300) t,(y(k),k=31,35)
I have never seen a program write groups of numbers to seven consecutive units before. Not that there is anything wrong with it.  glen





