I use DATA and SAVE sentences in STARCD's user subroutine to input the initial values to some arguments (arrays), but this action does not work well. When I run star in Linux (It is ok in Windows), the message 'Received signal sigsegv - exiting' is gotten and then STARCD quits the calculation. Does anybudy know what is the correct way to use DATA in STARCD's user subroutine in Linux? Maybe it is the another BUG in STARCD!

It sounds more like crappy coding to me, you might want to be a LOT more specific about what you are doing (hint STAR-CD has more than one subroutine), where does it sigseg, what does the subroutine do, are the arrays variable or fixed, how is the memory allocated, which version are you using and the list goes on......what sort of debugging have you done yourself and what are the results of it?

I use the conduc.f, coteet.f, densit.f and vismol.f. For example, in conduc.f code, I use the input code is:

dimension tscw(1:80),conscw(1:80)

SAVE tscw,conscw

DATA (tscw(ikk),ikk=1,80)/ arrays data /

DATA (conscw(ikk),ikk=1,80)/ arrays data / The STARCD version is 3.26.019 and the Absoft Fortran version is 9.0. The codes are OK for I can run them in Windows STARCD3.24 with Absoft Fortran 8.2 without any problem. In Linux, it is only ok to use the direct input sentence (i.e. tscw(1)=..and so on). Therefore I think the DATA input is a BUG in STARCD. Am I correct? What is your idea?

I'm slightly confused as to what you are doing, if you are trying to fill the two arrays with values between 1 and 80 why not just use:

DIMNESION TSCW(80),CONSCW(80)

DO i=1,80 TSCW(i)=i CONSCW(i)=i ENDDO

Are you sure the DATA statements are the issue? Have you tried debugging: "star -g -devtool=gdb", then in gdb do "run"; I'm assuming your machine has gdb. It should tell you which line is generating the sigsegv.

I think you are totaly not understand my question. Do you think my arrays are so simple like tscw(i)=i? Why not think them as tscw(1)=888.888, tscw(2)=666.666 and so on like more complicated arrays?

so what are you trying to do then? fill the arrays with different numbers?

Does the same kind fortran coding does the same on its own?

You can do a simple fortran coding and if it does not work it comes from the fortran, otherwise it is star-cd

Of course, it is the same fortran. I am not sure if you understand Fortran. Why not first try to use DATA input in STARCD by youself and then to answer my question? According to your anf BEN's marplot answers, now I am sure that it is a real BUG in STARCD. Actually, STARCD has too many BUGS except this one.

I have used the DATA call in hundreds of routines and never had a problem myself, when a case is crashing with user subroutines 99 times out of 100 it is a problem in the user coding and not the solver itself.

You might want to justify the bugs statement, yes STAR has bugs as does all other codes but the buggier part of the code tends to be pro-STAR and not the solver (they are developed by different parts of CD), again in my experience poor users tend to cry bug the minute anything goes wrong when in fact they just don't have the training and knowledge to use the code properly. Although I am sure you have attended the relevent training courses (i.e. basic and usubs) and are long experienced in using commercial codes! If it is a bug speak to the support if you are so worried but I am willing to bet good money its your coding!

In the right way, I have dealed with the problem using Richard's tips. It is not inaccurate in my coding. Could you tell us how do you use DATA call never had a problem by youself? What are the tips?

You still havent fully explained what you are trying to do, you seem to have two arrays but I am not sure what you are trying to do with them

I think the correct approach would be to use the same DATA declaration in a fortran stand alone program and in a user-coding from star-cd

if the stand alone program works and not in user-coding there is a problem with star-cd

Can you confirm you have tried the DATA statement in a stand alone fortran program and that it does not fail?

It should be very quick to check, below is an example:

DIMENSION A(5), B(3,3) DATA A,B /14*0.0/ !! 5 + 3x3 = 14...

!! check the size of the array = number

!! of data between //

to intialize only part of the matrix:

DATA (B(i,1), i=1,3)/3*1./ DATA ((B(i,j),i=1,2),j=1,2)/4*2./ DATA B(3,3)/0./

This forum does not keep carriage returns...

DATA (B(i,1), i=1,3)/3*1./

DATA ((B(i,j),i=1,2),j=1,2)/4*2./

DATA B(3,3)/0./

Yes. I have checked all fo the DATA call in stand alone Fortran program. It is no problem. However, in my case, the array is not so simple, every array's element has its own value, so I have to use 80 values inside / /. I also test my case in a stand alone Fortran program. It is Ok either. I can conclude that it is STARCD's problem if you will not use 'gdb' to run the subroutine with DATA call.

If you can conclude that you had better get onto support and ask them to check it out, let us know how it goes....I could do with a laugh!

I do not care if you do a laugh or not. It is your business. If the support of STARCD is good enough, I believe STARCD will have no so many BUGs. Too many BUGs in STARCD!!! Too many BUGs in STARCD!!!

go use something else then

Yes. CFX is better!!!

Particle-You do understand that this site is not user support and that nobody from CD is required to answer here? These are just other users. If you want help you have to call them up. Have you even tried calling user support? I find it mind-boggling that you can take a program that runs, add your own user subroutine to it at which point it stops working, and then claim there is bug in STAR. Assuming your code is right (who knows?) then maybe you have the wrong compiler version or patch or maybe you are trying to compile on an unsupported kernel or glibc. There are lots of possibilities other than bugs.