Problem with large numbers of CP's

[resammc]

Dear Prof. Taylor/Feap Admin,

Is there any limit in the number of knots/control points?

Due to some numerical reasons, I need to use a very large mesh (193x1000 control points), but when I try to run the model in FEAP, I get this error on the screen:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7F9057094E48
#1  0x7F9057093FD0
#2  0x7F90567C52EF
#3  0x4B7441 in pknots_
#4  0x50A138 in pnurb_in_
#5  0x50C99A in pnums_
#6  0x5034BF in pnewprob_
#7  0x57179F in pcontr_
Segmentation fault (core dumped)

I tried to track the problem and found out that the NURBS_count file is created, but there are some mistakes in the generated file:
the most important is in the beginning for the larger knot vector (which in my problem has 1003 knots)

in the NURBS_count file it is written:

KNOTs
  open   11003  0.00000000E+00  0.00000000E+00  0.00000000E+00  1.00200000E-03  2.00401000E-03  3.00601000E-03  4.00802000E-03  5.01002000E-03  6.01202000E-03  7.01403000E-03  8.01603000E-03  9.01804000E-03  1.00200400E-02
...

while my input is:

KNOTs
KNOT 1 1003 0.00000000, 0.00000000, 0.00000000, 0.00100200, 0.00200401, 0.00300601, 0.00400802, 0.00501002, 0.00601202, 0.00701403, 0.00801603, 0.00901804, 0.01002004,

as you can see, the KNOT VECTOR number is tied to the NUMBER OF KNOTS (instead of 1 1003, in NURBS_count it is written 11003). I would assume that this has happened because the placeholder for the number of knots is just 3-digits. I don't know if it has any effect in the final generated mesh or not.

I tried to look for the code responsible for this problem but couldn't find it.

Is it a known problem?

[Prof. R.L. Taylor]

Some of the errors have been noted.  The issue is dimensions for writes.  You will have to change some to allow for the larger number of knots and cp's

In this case the error is occurring in writing the NURBS_count mesh.  To correct the knots you need to change the format 2001 ink pknotlen.f (./nurbfeap/interpolation/pknotlen.f)  from 2i4 to 2i8 (I would also change the 2003 but we do not currently use it).

There may be other places too, I have never solved a problem with this many knots.

[resammc]

Many thanks for your response. I changed the value, that solved the problem with NURBS_count (the value in the file is fixed now and since the NURBS_count is deleted automatically afterwards, I assume that there is nothing wrong with that).

However, the error is still there. I tried to use NURBS ALL command in order to prevent any error related to the automatic counters but that also didn't help.

Any idea what could be another source of error?

update:

using gdb, the error is:

*ERROR* in NBLKEL: Block =    1 Side =   65 has inconsistent knot vector
         Knot =    0

Program received signal SIGSEGV, Segmentation fault.
pnblkel (nuren=0, tnume=0, knots=..., lknot=..., lside=..., nsides=...,
    nblksd=..., nblk=..., ktnum=...) at program/pnblkel.f:48
48                 if(nkn.ne.lside(2,nbs2)) then
(gdb) p lside
$1 = (( 0, 0) )

I checked the 65th side, in NURBS_count and it seems there is no error:

  side      65    1000       1   64001   64002   64003   64004   64005   64006   64007   64008   64009   64010   64011   64012...

update 2:

tried and interchanged knot vector 1 and knot vector 2  (also sides,...), same error in side 65.

[Prof. R.L. Taylor]

You will need to search for all the places in the program where "i4" formats for knots exist.  There must be several that are causing the problem.  Most are in /refinement:

Look at: pelvblk*.f; pelvout*.f poutblk*.f the * means there are 1d, 2d, and 3d routines.  The formats will probably have either the word "open" or "side" in them.

If you output a mesh, you should also change poutm.f in the /program directory

Hopefully, this will fix your problem.

[resammc]

Thank you very much for the help. The code works now. The last problem was from my side, not NURBFEAP. Your suggested change in the first reply does the trick and is sufficient (at least for the case where there is no refinement and the mesh is imported directly).