www.phidot.org

Hi,
I am getting a FORTRAN runtime error when trying to run a Multi-State Barker model (data type =176 and 178) on a computing cluster running Redhat Enterprise Linux 6 WS with the Linux 2.6.32 kernel. I am using the 64-bit dynamically linked compilation of MARK for LINUX users. I just re-downloaded the archived file to make sure there was not an update that I was missing.

Code: Select all

At line 1486 of file xmatrx.f90
Fortran runtime error: Index '0' of dimension 1 of array 'cdatyp' below lower bound of 1

I have been trying to trouble shoot this issue over the past week or so and have tried quite a few things listed below.

There was mention of a similar error on the phidot forum, but it was a size issue and an issue with the strata values. I still get the same error with a very small made up data set and all of my strata are a single character. I am able to get a multi-strata, live dead (no resights) model to run effectively under Linux. I am also able to successfully run the multi-state Barker model through the command prompt with both mark32 and mark 64 on my PC.

I was wondering if anyone had encountered a similar error or had any suggestions on things to try next.

Jess

Short of having your data file(s) o 'play with' my guess is that one or more of the libs you need for Linux-MARK aren't installed. Why I'm guessing that is that MARK is now compiled with gfortran 8.x.x, whereas RHEL (and clones thereof) comes bundled with (typically) gfortran 4.8.x. You can check which version of gfortran (and associated libs) you have by simply typing gfortran -v from the command prompt. If you have gfortran < 8, there is some chance your problem is because the gfortran libs you are accessing are too old. The only solutions are to upgrade gfortran (which might be tough unless you control the cluster), or, switch to a different distro which supports gfortran 8 out of the box.

I could try compiling a static version, and make that available, but that might take me a day or two (and, no guarnatee it would work any better...).

Gary sent me the most recent code for MARK, which I'm now compiling into both a dynamically- and statically-linked version of the 64-bit executable. I'll get that done, and run a few tests to confirm all is working, and then will tar both up and put onto the web by tomorrow -- noon EST at the latest.

Again, no guarantee it will solve the problem, but my gut hunch is it will...if nothing else, using a statically-linked version of the latest source code eliminates a few possible sources of problems.

cooch wrote:Gary sent me the most recent code for MARK, which I'm now compiling into both a dynamically- and statically-linked version of the 64-bit executable. I'll get that done, and run a few tests to confirm all is working, and then will tar both up and put onto the web by tomorrow -- noon EST at the latest.

Again, no guarantee it will solve the problem, but my gut hunch is it will...if nothing else, using a statically-linked version of the latest source code eliminates a few possible sources of problems.

New re-compiled versions of MARK using the 'fresh' source code -- both dynamically- and statically-linked versions -- are now online.

So, problem solved, or not?

Hi Evan and Gary,

Thanks so much for your fast response and taking the time to compile the most recent MARK code into both dynamically and statically linked versions. I am still getting the same error on my end. I will try to troubleshoot this a little further to make sure I am not missing anything and report back.

Thanks again!

I tried a few things, but still running into the same error pretty early on. My guess is that it is still a Fortran version conflict.

Thanks again,

Jess

Jpease wrote:I tried a few things, but still running into the same error pretty early on. My guess is that it is still a Fortran version conflict.

Thanks again,

Jess

Probably not -- if it fails with the statically compiled version, then there is probably another issue. You could check by running it against the Windows mark.exe. If it throws the same error with the Windows executable, then the problem is likely with the .inp file, or an outright bug (I'm betting on .inp file).

Thanks Evan!

Good to know. I just ran it against the Windows mark.exe with success and did not get the error that I was getting previously.

Jpease wrote:Thanks Evan!

Good to know. I just ran it against the Windows mark.exe with success and did not get the error that I was getting previously.

Interesting -- can you send me the file(s) you're working with offline, and I'll see if we can figure out what the issue is. In the meantime, you can apparently run the Windows version, so you can chug along that way for the time being.