Hi,

I keep getting segmentation faults when using the internal STAR routine 'LIVCLL'. I had it loop within posdat.f to 'scan' though a column of cell layers to see whether they are active or have been deactivated. It runs fine for the first few iterations but then will crash. Funny thing is, compiling my run as double precision seems to increase the number of loops that LIVCLL can go through before crashing.

Perhaps I need to increase some STAR variable to allocate more memory, somehow?

Tried checking stack size in Linux with ulimit -s. Says 'unlimited'.

Thank you in advance.

I don't know what the answer, but strange as it might seem, sometimes unlimited stack is worse than a reasonable limit. Just for grins, try setting stack to 64Mb. Its your datasize that needs to be unlimited. Steve

Erm, don't think I can set the stack size beyond 1MB. Linux defaults it to unlimited after that.

Nope, no effect. But thanks anyway, steve.

Unlimited datasize? What does that mean? Surely a 15k cell model wouldn't need so much memory.

You are right - a 15k model certainly does not need so much memory. I didn't realize it was so small. I would guess that it is some sort of coding error. Perhaps you are not calling livcll with the right parameters. You should contact user support.

Steve

I usually work in parallel: ask BOTH user support and this forum at the same time. Still waiting for user support but it's only been a few days so I think they'll probably manage to come up with something.

Thinking to substitute it with VOL(IP) instead of LIVCLL(IP,ISTAT). Can I assume that checking whether a cell' s volume is below a certain threshold (eg. 1.0E-10 m^3) can determine its active/deactivated state?

You can count on it if you know that all deactivated cells are collapsed because you are the one collapsing them. If, for example, you deactive cells because a valve closes and they are no longer part of the fluid stream, I think they would still have positive volumes.

Steve

Those would be excluded cells. Deactivated cells will be squashed by ProSTAR to zero or approaching-zero volumes in the direction specified by EDDI. Well, so far VOL(IP) seems to work though.

Unfortunately, I'm not the one that's gonna collapse and expand the cells during the run. I'm trying to give the usubs that freedom, since in this FSI case, the mesh motion cannot be known in advance, hence the use of LIVCLL, and some way of arbitrarily choosing which events to execute (CALL FLIP32, I reckon, but ain't working yet).