Mesh conversion via macro in FEAP8.6

[Jacopo]

Dear Professors, dear FEAP community,
I am experiencing issues with the macro for the conversion of a *.msh file to FEAP format.
Running the attached problem in version 8.6 causes the following error message:

Code: [Select]


MESH:square             
MESH:square.msh                    10
     Number Nodes    =     564
     Number Elements =    1130
        Type =  15 Part   =   0 Region =   1 NEL =   1 Node Point       
        Type =  15 Part   =   0 Region =   2 NEL =   1 Node Point       
        Type =  15 Part   =   0 Region =   3 NEL =   1 Node Point       
        Type =  15 Part   =   0 Region =   4 NEL =   1 Node Point       
        Type =   1 Part   =   0 Region =   1 NEL =   2 Node Line         
        Type =   1 Part   =   0 Region =   2 NEL =   2 Node Line         
        Type =   1 Part   =   0 Region =   3 NEL =   2 Node Line         
        Type =   1 Part   =   0 Region =   4 NEL =   2 Node Line         
        Type =   2 Part   =   0 Region =   6 NEL =   3 Node Triangle     
 *ERROR* ENDCLR: End of file encountered in TINPUT
         Unit Number =  15
Running the same example with FEAPpv5.1 does not cause any problem.
Does anyone have an idea of how to fix the issue?

Thanks for your help,
Jacopo

[Prof. S. Govindjee]

I don't think FEAP has a feature for importing *.msh files.  You will need to ask whoever wrote the macro.

[Prof. R.L. Taylor]

1. You probably need the file square.msh -- feap should add the extender to the filename you input.

2. Try the command:  gmsh,,square  - feap has changed passing the character array

[Jacopo]

Dear Professors,
thanks for your reply, but I could not fix the problem. Incidentally, I noticed that the program flow was affected by some write(*,*) statements. I thought that this could be a symptom of wrong array indexing, so I run the input with gdb and the -fbounds-check option, with the following result:

Code: [Select]

At line 193 of file umesh1.f
Fortran runtime error: Index '2583587' of dimension 1 of array 'hr' above upper bound of 1024

Error termination. Backtrace:
#0  0x7fb930e8cd21 in ???
#1  0x7fb930e8d869 in ???
#2  0x7fb930e8dee6 in ???
#3  0x55e82bc5fab1 in umesh1_
at /home/jacopo/FEAP/ver86/MUSAM_user/umesh1.f:193
#4  0x55e82bae1a26 in umshlib_
at /home/jacopo/FEAP/ver86/program/umshlib.f:34
#5  0x55e82bd3a3ae in pmesh_
at /home/jacopo/FEAP/ver86/program/pmesh.f:1866
#6  0x55e82bcad099 in pnewprob_
at /home/jacopo/FEAP/ver86/program/pnewprob.f:780
#7  0x55e82bab9a73 in pcontr_
at /home/jacopo/FEAP/ver86/program/pcontr.f:956
#8  0x55e82bab398b in feap
at /home/jacopo/FEAP/ver86/main/feap86.f:166
#9  0x55e82bab39ce in main
at /home/jacopo/FEAP/ver86/main/feap86.f:172
Do you have any suggestions in merit?
Thanks again for your time and help,
Jacopo

[Prof. R.L. Taylor]

That is not the problem.  The memory allocator goes beyond the dimension.  You can use valgrind to check things or the installed debugger

[Prof. S. Govindjee]

I agree the problem is not the hr( ) out of bounds message; that is expected based on our memory management system.  The error you are seeing is that the read loop in your umesh file is hitting the end of the input file (I guess your *.msh file).  The do while loops are looking for blank lines to terminate, so I think your *.msh file must be missing a blank line termination some place?  or perhaps you need an additional blank line in Isquare after all your gmsh data.

I also see that your umesh is performing direct reads from ior.  tinput/pinput is maybe a better idea.