FEAP User Forum
FEAP => Input File Issues => Topic started by: ws18 on July 05, 2017, 09:22:34 AM
-
Dear all,
I have a thermal-mechanical user element (staggered scheme) which works well in the FEAP8.3. However, in FEAP8.5, it seems that I cannot use BOUNdary command to define boundary conditions.
If I just use EBOUNdary or Cboundary to define the boundary conditions, the element works fine. I tried to use the command BOUNdary define B.Cs, I can plot the boundary restraints before I apply the PARTition command. However, the boundary restraints "disappear" after I apply the PARTition. The computation gives garbarge results or cannot get convergence.
Is there any update in FEAP8.5 leads to this problem? Do I need to pay special attention to the usage of BOUNdary command in the staggered scheme (Or partition case)?
Thank you.
-
Can you please post a simple input file that illustrates the problem. No need to post your element, just an input file.
-
Two input files are attached. Thank you!
-
Please give a short description of the two files and what is and is not working in them.
-
For the first example, you can check that if you use the EBOUndary to finish the B.C definition, it works well. But if you use BOUNdary (as the inputfile shows), the restraints are not successfully prescribed.
For both examples, you can check that before the applying of the PARTition command, the boundary conditions can be plotted even if the command "Boundary" was used. However, all restraints seems disapper after applying PARTition.
-
I ran your input file (Ipartition) in ver8.5 and it shows boundary conditions you set before and after the partition command. I see the same boundary conditions in both cases. We know that 8.4 had an error and did not work with partitions, but 8.5 has been corrected.
-
Dear Prof. Taylor,
Thanks for your reply. The first plot shows the boundary conditions before I set partition command and the second one shows the B.Cs after I set the partition command. As you can see, all the B.Cs specified in the inputfile are plotted in the first one. However, only the B.Cs specified by the CBOUndary can be shown in the second plot.
I also have the monolithic element and it doesn't have the issue in the B.C definition. Could it be possible that I should make some changes in the stagered user element?
-
Could you try replacing your element with the standard small strain feap element. This is done by changing
USER 3
to
SOLID
I want to make sure that it is not your element that is causing the problem -- since this is what I used when I ran the mesh.
-
Dear Prof. Taylor,
My test shows that the built-in thermal-mechanical solid also has the same issue in my computer.
I also ran the test-example (benchmark example) named "Ithmech_2d". For this one, it seems ok when I try to specify the B.Cs by using command BOUNdary.
-
It is hard to understand why your program does not work and ours does. Can you do the following please.
Run the problem and before the partition command issue
SHOW ID
do the partition command inputs and then give the command
SHOW ID
Do not more solution commands and zip the output file and post
Also tell us what is the version of your compiler and what operating system you are using and if it is a unix/mac/windows machine.
-
Dear Prof. Taylor,
The files are attached. I use the Mac with the system OS X 10.11.5. The compiler is GNU Fortran (GCC) 5.3.0.
-
What level of optimization are you using? Maybe the compiler is making an error if it is too high. We never use more than O2 usually.
I can see the boundary conditions are gone after the partitions are input -- can you add the following statement in pcontr.f (./program directory). At line 877 of the file the array ID is allocated for the boundary conditions and equations. add a line before the call
call iprint(mr(np(31)),ndf,2*numnp,ndf,'ID_before')
and after the allocation
call iprint(mr(np(31)),ndf,2*numnp,ndf,'ID_after')
Run the problem to just after the partitions are input.
Also change the loop 3 lines after to read
do j = 1, maxnpart (instead of npart)
Report the findings (post the output).
This is the first place they could be lost.
-
Its maxpart not maxnpart
-
Dear Prof. Taylor,
I didn't increase the Optimization lever when I install FEAP. I attached the makefile.in file.
I made the change in pcontr.f. You can check whether my changes are what you want. The output file is also attached.
Thanks a lot for your time.
-
Can you re-do the prints of the ID array before and after, using a 1-element mesh?
-
Also, repeat the test using EBOU instead of BOUN with your original problem and the one element one.
-
Dear Professors,
I found a very strange phenomenon. The BOUNdary can work if the element number is less than a certain amount, say, the test shows that the mesh with 3*3*1 can work but the mesh with more elements cannot work anymore. It seems that the effectiveness of the command BOUNdary is node/element amount dependent.
Since the one element mesh does not have this issue, I output the 4*4*1 mesh case. I also attached the inputfile and please take a look if you have any doubt on the inputfile.
-
So that we are certain about what you are running. Please run the attached two input files and post their output.
Also before doing so, please remove any user elements etc. from your executable.
Further, do you have the possibility of using a different compiler? either the Intel compiler (free for students) or GCC 6.x?
-
Dear Prof. Govindjee,
I ran the two files without any user element or material change. But I kept the change on the file pcontr.f recommended by Prof. Taylor.
In terms of using a different compiler, I can try do this and inform you my finding this weekend.
Thanks for your time.
-
Ok. Here are two more files to run (leave Prof. Taylor's changes in your code).
-
And one more set...
-
I ran all the four files. Output files are attached, please check.
-
Ok. Time to keep diving further down the rabbit hole. In unix/memory/setmem.f, look for freallocfn( ) and change the code to look as follows:
! Compute length in integer*X recast to integer*4 for malloc
! X is either integer4 or integer8
point = length
longv = int((point*ipa + mod(point*ipa,ipr))/ipr)
if(n.eq.31) then
write(iow,*) 'point ',point,' longv ',longv
call iprint(mr(np(n)),ndf,numnp*2,ndf,'before frealloc')
end if
call freallocfn(np(n),longv,ip,ipr)
if(n.eq.31) then
call iprint(mr(np(n)),ndf,numnp*2,ndf,'after frealloc')
end if
so you are just adding the if blocks before and after the call to freallocfn. To run this, you will also have to add
include 'sdata.h'at the top of the file.
Now re-run Ipt1newd and Ipt2newd
-
In addition to the above changes, please also make the following changes to the function "static offset_t reallocfn( )" in unix/memory/cmem.c (starting around line 273).
(1) Before the line q = (byte*) realloc..., add the following two lines:
int i;
for(i=0;i<200;i++) printf("%d ",*(p+p_shift+atomlen*i) ); printf("\n\n");
(2) After the line q = (byte*) realloc..., add the following line:
for(i=0;i<200;i++) printf("%d ",*(q+p_shift+atomlen*i) ); printf("\n\n");
(3) Before the line memset(&q_cmem_data..., add the following two lines:
printf("p_shift %d, q_shift %d\n",p_shift,q_shift);
for(i=0;i<200;i++) printf("%d ",*(q+q_shift+atomlen*i) ); printf("\n\n");
Re-run Ipt1newd and Ipt2newd. This time there will be output to the screen (a bunch of numbers). Please post the numbers you get for each run.
-
Dear Prof. Govindjee,
I made the change on the setmem.f, the output files are attached.
For the changes on cmem.c, I don't know how to make the changes effective. I cannot compile it just like setmem.f, right?
-
do the following.
(1) make a copy of cmem.c to say cmem_save_c
(2) edit cmem.c as indicated
(2) cd $FEAPHOME8_5
(3) make
This will compile cmem.c and update your archive with the modified version. Once we figure out the problem, you can move your cmem_save_c back to cmem.c and remake your program.
-
Dear Prof. Govindjee,
First, I installed the FEAP8.5 in my laptop using gcc 7.1.0. The same problem exists. My laptop system is mac OS X 10.11.6.
Secondly, I followed your suggestions exactly to do modifications on cmem.c file. However, it gave me the "memory" fault after I make it. I tried many times, I cannot get my FEAP recovered by just modify the cmem.c back and make it. I need to reinstall the FEAP. I don't know where I am wrong.
I noticed that the cmem.c file also exists in the folder "largemem" and I copied it with cmemck.c to "Unix" when I install the FEAP. Can we only make changes on the cmem.c file in the folder "memory"?
-
Your compiler and OS should be fine.
Step 0: Compile and run the program memprobe.c in the maintain directory: gcc memprobe.c; ./a.out This will spit out some configuration information (that hopefully you have already followed).
Step 1: Make sure you can build a clean version for FEAP; no edits to any files, no added files. Just unzip/untar a clean version of the code and make it. Test the feap executable to make sure it works. This is to ensure that your toolchain is correct. You can also post your makefile.in.
Step 2: Edit the cmem.c in unix/memory as I indicated.
Step 3: Go to your FEAPHOME8_5 and type make
This should produce a working version of feap in main that your can now run.
-
Dear Prof. Govindjee,
It seems I find the problem. I think your FEAP8.5 is fine. The problem is that I used "integer 8" but set ipr=1 in the file fear85.f (in main). I think I should set ipr=2, right?
The comments in the feap85.f and makefile.in said that ipr=1 if the compiler option set all integers to be integer*8. I followed those comments. But I think ipr should be 2, is this understanding correct? Are those comments correct?
I can define B.Cs using Boundary now. My user element can also work.
-
Yes! ipr = 2 for your machine. The meaning of ipr is "integers per real". The standard integer size is 32bits and the standard (double precision) real is 64bits, hence 2 is the correct value. The use of integer8 refers to the native size of the pointers for your OS/hardware combination. In your case, with a MAC your machine is using 64bit pointers and thus we store the pointers using integer8 declarations.
The only time, with any modern hardware, that you would set ipr = 1, is if you were going to force all standard integers to be 64bits with a compiler flags such as -fdefault-integer-8 with gfortran, or -i8 with ifort. The utility of this option would be to allow even larger problems to be solved, since it would allow any single array in FEAP to have more than 2 billion entries.