Programming in Fortran - Science topic

To resolve this issue:

1. Double-check the file or directory path: Verify that the file or directory in the error message actually exists in the specified location. Make sure there are no typos or missing files.

2. Check the working directory

3. Include search paths

4. Verify file permissions

5. Check dependencies

Good luck

Dear Abdulrahman Ashmawi ,

the material properties in props array of a umat are constant for the whole analysis and are defined in the material card at the preprocessing stage. If I understand correctly, you have developed a user material that calculates the stress update and the material Jacobian for each increment. In that case the material properties that are needed for your calculations would be retrieved from the meta database (you need to have access of this database in the umat) and not from the props array that is passed as argument in the umat. Then you can proceed with the calculations using the correct value of your material properties.

Dear Anji Babu Kapakayala ,

did you read "Five-step FFT algorithm with reduced computational complexity", please see the follwoing link, may be it will help you.

Dear Vishnu,

in which format is the data, which you would like to interpolate, available: NetCDF, ASCII-Text, Excel, ... ?

Hello,

I send you two graph of our function erf(z) depending of y where z=x+iy for x=10 and x=1 with.

Best regards,

Bryan.

Google scholar webpage: https://scholar.google.co.id/scholar?q=Two+surface+model+%282SM%29+%26+Three+surface+model+%283SM%29&btnG=&hl=id&as_sdt=0%2C5&as_vis=1

see

You may like to use an open source automated PDE solver such as Fenics:

You need to do a minimal coding (either in C++ or Python ) for writing a variational form for your problem and defining the input functions.

.

Dear Marcus,

thank for the answer. I had gone through those link. I would like to if ask is there way to convert fortran binary file into text file without any alteration ?

SOLVED!!

it's simply due to the incompatibility of your microsoft MS-MPI product.

Please uninstall your current MS-MPI package and install with "msmpi installer" from your Abaqus installer DVD (iso).

I have benchmarked both linux and win versions of Abaqus 6.9 on the same workstation (8 cores) and the linux version run faster. I attributed this to better handling of memory and efficient hard drive writing.

Hi Ryan,

The SIGINI and VOIDRI subroutines supply the initial stress components and voids ratio at the integration points of the mesh elements. May I ask why you are using these?

My experiences of these subroutines is linked to my research into extrusion of particulate pastes, which can behave as soils in that the pore fluid and solids matrix can phase separate over time.

Extrusion involves very high strains (10000% or even higher). Thus, the finite element mesh becomes very distorted and one must periodically replace or repair the mesh to continue the simulation. I used the replace approach in the above papers, which meant I had to stop ABAQUS periodically, draw a new mesh with external code, interpolate the stress components, voids ratio and pore pressure from the old mesh to the new mesh and restart ABAQUS using the interpolated data as initial conditions. I used SIGINI and VOIDRI to supply the interpolated stress components and voids ratio at the integration points (IPs) of the elements in the new mesh. SIGINI and VOIDRI are called for each IP within each element. So if you have a 100 element mesh with 8 IPs per element and 6 active stress components per IP, VOIDRI will be call 800 times as ABAQUS initialises the simulation, while SIGINI will be call 800*6=4800 times.

Within the SIGINI subroutine, ABAQUS will tell you which particular element and IP number that the stresses are being requested at. This will change during each call of SIGINI. Back when I was using ABAQUS 6.12, SIGINI did not call for the elements in ascending numerical order, although once it requested stresses for element X, it did request them at the IPs for element X in numerical order, i.e. elem X at IP 1, elem X at IP 2, etc. Thus, SIGINI passes in the element and IP numbers as arguments for you to use when you are calculating the stress at that location. In version 6.12, for some stupid reason I never understood, VOIDRI passes in just the element number and not the IP number. I dealt with this ambiguity by testing and realising that VOIDRI is called for the various elements and IPs in exactly the same sequence as for SIGINI - thus, whenever SIGINI was called, I stored the integration point number argument that it use (NPT) to an external file that VOIDRI then accessed immediately afterwards. SIMULIA may have fixed this unbelievably stupid omission since then, so do check if the argument list for VOIDRI includes the NPT argument which is defined for SIGINI.

With respect to my particular code, I defined the stresses and voids ratios in external text files and opened them at the start of the simulation using the UEXTERNALDB user subroutine. That allows the files to be accessed by SIGINI and VOIDRI during initialisation. Anyway, reading in all of this data meant that ABAQUS was spending a long time reading data off my hard disk . I was able to speed this up by changing the default type of file reading used by ABAQUS ('sequential access') to a much faster type called 'direct access'. This requires that the external data files have a fixed number of characters in each line ('record length'). Thus my code is not the simplest example of SIGINI/VOIDRI usage. However, if you have a little coding experience, you should be able to pick up what I am trying to do in the subroutines.

Anyway, let me know how you go.

Milan.

Hi, I always use:

*CONTROLS, ANALYSIS=DISCONTINUOUS on Step part.

The another way is:

*INITIAL CONDITIONS, TYPE=STRESS, FILE=(Your previous step).odb, STEP=1, INC=1

Change GRAV to Body force.

Good luck

Hi Farhad,

You could try Calculix. I've used it for running ABAQUS-like input files, although I haven't tried out its user subroutine interface.

Let me know how you get along - I am curious :)

Milan.

Strain and Stress both are vector quantities, but energy is scalar one. So you may be trying with the same format as you are doing for stress and strain. After reaching to the values[0], do not try to get the data with direction i.e values[0].data[1] etc. I am writing an example below. You can try in same way. I hope this should solve your problem

Energy = ELEN.getSubset(region =    ,position = centroid)

Finalenergy = Energy.values[0].data

hi

you can use in fluent this instction

file -import -mechanical apdl- selected all file and insert your file.eps .

The same for the second equation

It's been a while since I worked on this, but I think the two files here should help you: I used a user-defined boundary condition to store the position of the tool tip so that elements are only deleted there; the deletion is done using VUHARD with a johnson-cook law.

Dear Professor Surender Singh,

Thank you very much for your help.

There are a few areas where I can see that your code might cause a problem ... you have two WRITES and a PRINT ?? How much output are you trying to generate? Did you notice that your WRITE format statement skips 18 columns (18x), and does this 800 times? If you really have 800 wide array, your RECL is not correct (1200). Are you sure you have the correct syntax for reading scientific notation?

Some basic text on FORTRAN input and output will help. If you are an expert and just having some small problems,the areas I mention above might help.

Dear Hamed,

I am pretty sure you can find CICSAM implementation in OpenFOAM. you may have a look at the extended foam project. It would be in C++ but that would probably make it easier to understand what you need to do. You can also find Obbink thesis easily (Numerical prediction of two fluid systems with sharp interfaces) which will provide more details if you don't already have it.

Good luck

Sina

Thank you so much, Graeme.

Long time no see!

All the best.

Tony

thank you Dr. Scarlato. 

What is your reason to pick FORTRAN for this task? The major disadvantage I see is that you can either write modern Fortran or fast Fortran. You cannot have both at the same time. (I had this proven to me by someone from the Fortran standardization committee. If you write proper object-oriented code in Fortran it might be slower by a factor of 100.) There are other languages out there that make it a lot more easy to write readable, modern code without any impact on performance. And believe me that readability can save you hours. If you are interested in this discussion I can try to find an old thread here on RG about which language to use for numerical problems.

Thank you Sir for your response, I have already written in 2014. 

You did not ALLOCATE an array that is defined as ALLOCATABLE. You have to introduce a line

ALLOCATE(F(60,60))

before assign any value to the array. Now the program is running.

  Your example works for me,

$ pwd

/home

jjc@hpc03 /home

$ ls /cygdrive/c/cygwin/home/jjc/hello.f

/cygdrive/c/cygwin/home/jjc/hello.f

jjc@hpc03 /home

$ g77 /cygdrive/c/cygwin/home/jjc/hello.f

jjc@hpc03 /home

$ ./a.exe

hello

The directory structure for cygwin looks

strange, though.  I always see

/cygdrive/c/cygwin/home/

as the directory in which user's home directories are under.

  In your last command, change g77  to ls

My guess is that you still get No such file or directory, since I believe that

this has nothing to do with the compiler, but has something to do with the Cygwin install.

Dear   SOUFYANE BENMENZER 

Please see the attached report, it may help you on how to treat the solid regions.

Please provide more explanantions as I did not understand your question.  

YES, you can use FORTRAN. You can use the CCL  (CFX Command Language)  through the expressions, or as Arun has written, with Pearl scripts. You can generate  calculations routines, procedures to post processing in the CFD-Post. Some calculation procedure as turbo machines or FFT are native in the software.  

If you need a specific calculation, define source term, a boundary condition, or other expression to be evaluated in execution time by the SOLVER you can use also Fortran user routines  or CCL. In the newer releases, the CCL became more flexible  working with gradient, and IF statement, what avoid the  Fortran coding. But  it depends on the case and the complexity of your problem. 

Attached it has my PhD thesis. Is in portuguese, but does not matter. In the appendix you will find a CCL  example with a a momentum source  with dot product of a Tensor and a gradient Vector. Look  for EXPRESSIONS. In early versions, this procedure   would be made with FORTRAN subroutines. The other  parts of script  regarding to setup. But is also part of CCL . 

wgrib offers the possibility to create readable binary files or a text file (without headers). But if you want to be more flexible, I would also suggest the grib api, which is generally also much faster.

If you have grib2 files, you might want to consider wgrib2, which can put out stats of each message by using the command wgrib2 -stats file_name.

I agree there are no miracles ! You either choose to make your code portable, in which case you provide the source code and let your IDE do the work, or you optimize/tweak the crap out of it and compile the modules yourself, but in that case you have to stick with the CPU/architecture you are working on.   As they say, "there's no FREE LUNCH".   What a pitty :(

As far as I know there is no function directly available in Fortran. The easiest way to do this is to write a function in C which uses according functions from the operating system and computes the information that you need. Then, you call this C function from within Fortran. For this you need an interface written in Fortran which will fit the interface of the C function (the Fortran keyword BIND(C) is very helpful for this).

What Hamidreza mentioned about unintentional copies being made there is a way to figure out where this occurs. The compiler will not tell you directly. But, when you compile with ifort using the flag '-check all' you will get runtime warnings when copies occur. You should be aware, though, that this compiler flag turns off all optimizations. Because of this your software will run up to 10 or 20 times slower.

you could use a format as follows:

100 format(6(1x,f12.6),a1)

do i=1,nrow

write(10,100)(mat(i,j),j=1,6),achar(38)

enddo

**** or

100 format(6(1x,f12.6),'&')

do i=1,nrow

write(10,100)(mat(i,j),j=1,6)

write(10,100)(mat(i,j),j=7,12)

enddo

****

the achar(38) is ampersand... the following program will give you part of the table.

program achartable

do i=1,200 ; write(*,100)i,achar(i) ; enddo

100 format(i3,1x,a1)

end

****

please give your feedback

Personally I cannot advice something, but compilers are widely described in the TRNSYS user community - http://lists.onebuilding.org/pipermail/trnsys-users-onebuilding.org/. Try to search there.

The clock rate of current CPU cores is not a really important feature nowadays due to parallelization and their current performance. The number of cores is important in this regard, but the efficiency of parallelization mainly comes from the software implementation as well, and will greatly depend on your target application.

If you look closely at the current CPU performances, more time is spent on data access than actual computation for finite element softwares. Critical parameters thus also include the cache sizes and the memory transfer speed of your CPU, (the time needed to tranfer data from different cache levels to the unit). You should also check clock rate of your RAM for the same memory access time reasons.

Depending on your application mutlithreading capabilities (virtual parallelization at one core level), like for recent Intel i7, allows memory sharing that can accelerate some operations such as matrix vector products. Dual RAM channeling capabilities speed up the memory access and can also greatly improve performance in some cases. These capabilities are worth checking.

Commercial codes have made a lot of progress regarding the exploitation of parallelization but their generality make it impossible to provide best performance everywhere. Since every CPU architecture have their pro's an con's regarding final performance it is very difficult to get best performance for several applications.

You will nevertheless get good performance with the most recent workstation hardware setups that usually provide 4 to 8 cores (if you have enough RAM not to swap). Paying attention to the cache memory sizes and transfer speeds will definitively help making a relevant choice.

As far as I know, the procedure is exactly the same (of course for a 3D case you should provide the three components of the position and the velocity vectors). In my case I wanted to simulate one single particle falling into a static liquid, and it was simple. For example in one of the cases I simulated, the particle_input file contained just the following line:

5.0000 148.0000 5.0000 0.3625E00 2.164 0 0 0

in which the first three number defined the position, 0.3625 was the particle diameter, 2.164 the particle density and the final three 0 are the velocity components (in my case the particle was at rest).

The use of the particle_input file is convenient if you plan to simulate a case with a limited number of particles, as you should provide particles' infos for every single particle.

In the case of a 3D fluidized bed, for example, you can turn on the automatic particle configuration (GENER_PART_CONFIG = .T.), which, given particle diameters, void fraction and the coordinates of the domain in which the particles are stored initially, generates automatically the particle number and positions (see pag. 91 of the Readme.pdf file).

Cheers

Seyed,

Even if the environment doesn't offer any particular tools, the old 'tried and tested' method of liberally sprinkling the code with reporting WRITE statements (indexes of loops, simple line reports to see where the code has got to, etc.) isn't a bad first attempt.

How big is the code and what sort of problems are you encountering?

If what you need are complex random numbers with property |z|<=1 and uniformly distributed within this unit circle (not the case of previous comment by Diogenes Alves!) then you can act like this (f90/95, just a sketch, far from being optimal):

subroutine crandom (z)

complex, intent out :: z

real :: x, y, s1, s2

call random_number (s1)

call random_number (s2)

do

call random_number (x)

call random_number (y)

if (x*x + y*y .LE. 1.0) exit

enddo

x = sign (x, s1-0.5)

y = sign (y, s2-0.5)

z = cmplx (x,y)

end subroutine crandom

gfortran is one of the compilers for which -O0 is the default

this makes for fast compilation, but poor run-time.

This may also be an additional source of frustration.

Being in High Performance Computing, this is not the behavior that I want,

so I always use -O or -O2 with gfortran

You can verify this by comparing the output of

gfortran -Q --help=optimizers -c secondr.f90 | grep enabled > opts_default

and

gfortran -Q -O0 --help=optimizers -c secondr.f90 | grep enabled > opts_O0

and

gfortran -Q -O1 --help=optimizers -c secondr.f90 | grep enabled > opts_O1

Then

diff opts_default opts_O0

returns nothing, (identical)

while

diff opts_default opts_O1

Similarly, just specifying -O appears to mean -O1

at least in my version of gfortran, version 4.4.6

1) define compiler flags:

F90FLAG=-fPIC -Wextra -cpp

LIBFLAG=-fPIC -shared -ffree-form

2) create the object file for each source: gfortran -o example.o -c example.f90 $(F90FLAGS)

3) create the shared library against all the objects just created: gfortran -o libuser.so $(F90OBJ) $(LIBFLAG)

Step 2) is equivalent to makefile command:

%.o: %.f90

gfortran -o $@ -c $< $(F90FLAG)

I can send a working example if you need.

We found a solution: creating the file with the option NF90_SHARE :

nf90_create(ncfile, NF90_SHARE, ncid)

What compiler is best depends on how you use it. From my experience with Fortran under OSX.

Free compilers:

1. G95 - Slow and a little quirky, but great for code development. Your executable will respond to a lot of different environment variables that allows you to tweak the post-compilation behaviour, which can be very useful. Might not work with legacy f77 code, since it is strictly a f90 (and higher) compiler, which does not support all old f77 extensions, like cray pointers.

2. gfortran - Good allround compiler.

This one you have to buy:

3. ifort - Great for speed, and it comes with the very good MKL library for fast maths, so this is probably the best compiler for running your application. BUT: avoid using ifort for code development, as it is (in my opinion) "too good" at interpreting badly written code. Code written with an ifort compiler has a tendency to be very hard to port to other platforms, and I harbour dark suspicions that it sometimes quietly interprets erroneous code.

Apart from that, unless your project is very small, you will need a debugger, preferably gdb which is available anywhere you have gcc, and valgrind which is great for memory debugging.

Links: