Hi there!

I've been working with Star-cd version 3.22 issued in 9th of june. But often have to change computer and the version installed in this computer is 3.103.522.

When a save my .mdl file, it does not give me an option to lower the version of the file, so a can transfer the work to the lower version machine.

Is there a manual way to lower the versions?

export data -> export grids -> pro-STAR then export boundaries

This should work for the grids and the boundaries, you will probably have to re-set up physical properties, boundary conditions, analysis control etc. You can try reading in the echo file but a lot of the commands arent likely to be recognised.

Although if I were you I would just get 3.24 installed on the machine, any idea why you have to use such an old version anyway?

Its better to do a "cdsave" (file - save as coded) so you also get the settings.

Regarding 324:

V310B was a very good release and v315 is also not too bad.

3.2 is getting there now

But if your application runs fine in one older version, then not everybody wants to switch.

I already spend more than a month computing time this year with v32 and ccm+ to trow away the results in the end because of bugs.

There is something to be said for using old versions certainly, if it aint broke why fix it after all.

The only thing you miss out on is new models and enhancments, and of course support (as they stop supporting older versions after a while)

Dare I ask how you manage to loose a month out of six of computing time due to bugs? Surely you should check your results frequently enough to know when something is going wrong? (and if it is, contact CD)

It is sometimes not easy to convince the support that this is a bug and not a new feature So you run withthe old version and then with the new one ...

And if you have calculation which run without problems already for several years you don't expect that there might be something wrong if you switch to a new version.

I've wasted huge amounts of time trying to prove to CD that bugs exist in their code - especially if there are subroutines involved. One particular time I was asked to provide a simplified case that still crashed. So I took as much code out of my subroutines as I could and eventually ended up implementing the exact same model that's already in STAR.

Their response was to question why I was running STAR in such a strange way ...

"Why do you need a subroutine that's doing the same as our default models? Remove that and your problem will go away."

sounds like a fair comment to me!

"sounds like a fair comment to me!"

Maybe you missed my point...

I find that STAR crashes if I use a subroutine to do things STAR can't do. I tell them, they tell me it's probably bad code in my subroutine. So I reduce my subroutine so that it's trivial and only implementing their basic model anyway - in this case the results with and without the subroutine should match. But the subroutine version still crashes. Hence I have demonstrated that the problem is code infrastructure related and not a problem with my code.

Then... I'm asked why I'm using such a simple subroutine in the first place!

After another round of emails between various support staff who seem to have never met each other, I get the great answer of "use patch 010.234.543.beta.Tuesday" (or something similar). And if that doesn't work I get yet another random patch to try.

Iterative patching to work around intrinsic bugs is not fun. I'd rather be told what the bug was and why this particular patch fixes it. Otherwise bugs tend to come back, giving rise to the concept of "Vintage versions" - those that were relatively bug-free compared to other versions.

dare I ask the specifics of the model you are trying to implement?

Nothing particularly complicated, just user gas properties (densit & specht) and boundary conditions (bcdefi). Restarted models would diverge almost instantly, even with really trivial cut-downs of these subroutines.