Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

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:+

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:

I call on two subroutines here is the beginning for the main routine:

      implicit double precision (a-h,o-z)
      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 (a-h,o-z)
      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 (a-h,o-z)
      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:

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 un-set variables and array accesses out-of-
bounds are suspects.

That the program fails when you increase the size of an array suggests
that your are over-writing 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 e-mail me your source code and data if you would like.

Good luck.

-- e-mail: 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

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc