How many nodes can you work with?

JRP

I see. I didn't expect this limit. And yes, I have a lot of T connections, because I'm working on a structure made out of steel tubes. It is also very tricky situation, because I invested a lot of work into model and then I get this error. I will be able to save the work with few workarounds.
Is it possible to predict ahead when this will happen?

Victor

Sorry if you're going to lose work. One workaround may be converting to quad4 if there are separate parts having no triangle elements (due to lack of tri3 shells with internal solver). Or maybe the CCX solver if you install one of the higher-memory ones like perhaps Pardiso. I suspect most of the easily available compiled ones may have the same limitation though.

That error message

Array dimensions exceeded supported range

is new to me. It looks like it's due to the internal arrays using 32-bit indices which limits them to 2^31 = 2 billion elements, not 2GB as I previously stated. Since they're double precision, that's 2G * 8 bytes per array element= 16 GB. That's before solving. During solving it fills in some of the zeros ballooning the size, so even if it was possible, it might be blocked by some other memory or integer limit too.

It's not easy to predict the size by hand since it depends on each element's number of connected elements but I'll see if I can get Mecway to calculate this and show a warning or something if it gets too big.

prop_design

i don't know if this helps anyone or not. the reason i originally created this topic was to get an idea of how much memory i should get. i originally had a laptop with 4gb of memory. i now have one with 8gb. from working with mecway and ccx i can tell i need as much memory as possible. right now, that's around 64gb for a normal computer processor. prior to using mecway, i used ansys. ansys was better at solving large models. meaning, you didn't need as much memory as mecway and ccx. in particular, contact and cyclic symmetry is a lot more usable in ansys. in any event, the reason i check the node count is to get an idea if the model is going to solve, prior to trying to solve it. i generally don't use contact. i made a model with contact to help a forum user out. people started using that model for benchmarking. contact throws a big wrench into the idea of checking node count. the number of contact pairs adds a lot of degrees of freedom to the solve. i think this is similar to what you guys are touching on now. when i asked the original question i was talking about tet elements with mid-sided nodes and no contact pairs. so yeah, this whole topic can vary greatly on it's usefulness. i still check node count before solving though. for me, it's still a useful way to gauge the solve time, prior to solve. lastly, another place i saw a big variance with this is with laminates. since ccx expands them, you can't really use this method. you don't know what you are going to get ahead of time. so the midplane might have few elements. but if you have a lot of layers and they get expanded the dof the solver is seeing will be drastically higher. it used to be simpler back in the day. so that is what this topic was originally geared toward. the ultimate thing you would want to know is the dof the solver is dealing with. however, you can't see that until you are actually solving the model. but if you track that in a spreadsheet, for various models that you solve, then you can start to get a better idea of the limit. i don't know what the mecway/ccx limit is as opposed to the ansys limit. you would think any program would have the same limit. however, working with the programs, it doesn't seem that way. i could have tracked this metric, but that defeated my goal. i wanted to know prior to solve. so the only way to do that was to track node count.

JRP

The thing is that I don't do nonlinear analysis if it is not very necessary. So when I was modelling one model before this, which had around 150.000 elements and 500.000 nodes and it solved in 2 minutes I didn't show too much care to 300.000 elements and 1e6 nodes. Worst case scenario would probably mean about 5 to 10 minutes of calculation, which is nothing for me. But then I got this error and I discovered a limitation I knew nothing about.

I can't go with quad4 elements, beacuse tri3 are not supported in Internal solver, as Victor mentioned. I have them in my model and can't do much about it. I also don't want to go through with CCX solver, because it has other limitations I don't like.

For now I solved this with calculating parts of the model in separate files and it goes through.

It would be very very useful if we could get warning report if one gets close to this limit.
I usually mesh with quad4 and tri3 elements and then change them to quad8 and tri6. Then I also usually use one plane to mirror everything through, because my structures are usually simmetric in one plane.
Warning would be great, because the mesh can be corrected in the beginning without doing any aditional work on the model, after which the mesh correction is much more difficult.

Victor

Good news. There's an easy way to prevent the Array dimensions exceeded supported range error which can also occur elsewhere like displaying a big mesh or reading the solution from the CCX solver.

Copy this Mecway.exe.config file to the same folder where mecway.exe is installed, which is typically C:\Program Files\Mecway\Mecway13. Overwrite the existing one.

It includes a setting that simply turns off the size limit! If it doesn't show any side effects, this fix will also be included with the next version (14) which is coming soon.

JRP

That's great. It works. Thanks.

Sergio

Has somebody experienced the fact that a big problem was succesfully calculated (according to the CCX log), but there are no results at all? Today I solve a lineal problem that took about 30GB (of 32 available, all the rest was for Windows and Chrome) of RAM, and maybe 10 minuts of CPU time... to get no results. I took the .inp file and solve directly with CCX from command line (to save the memory of what could taking Mecway GUI to show the model) with same results, the log says that was succesfully solved, a .frd result is created, but no result at all :-(

I have sffered this same issue with several big models.

Victor

I seem to remember the usual behavior when it needs too much memory is to leave an empty .frd file and abruptly exit with no error message. Don't know about the log file though. Is it that?

JRP

I had a problem with CCX buckling solving and it solved but there were no Modal values results available. I wrote to Victor and this is what he wrote back:
---------------------------------------------------------------------------
That looks like out of memory (again!) due to too many nodes with the default CCX that comes with Mecway. However, you can download CCX compiled for MKL Pardiso which lifts that limit and should be OK. Instructions in option 2) of this post: https://mecway.com/forum/discussion/comment/4255/#Comment_4255
---------------------------------------------------------------------------

Maybe this can help you...

Sergio

I'm using CCX 2.17 with Pardiso, but as far as I know is "in core" version, that will try to fit all the model inside RAM, there are other cersion "out of core" that put some part of the model in disk if RAM is not enough.

aliva13

Encountering limitations in element types and solver choices can be challenging. Your approach of dividing the model into separate files for calculation is a practical workaround. Implementing a warning system for approaching limitations, especially during meshing, would indeed be beneficial. Early notifications allow for preemptive adjustments. Communicating this need to the software developers could potentially lead to future enhancements that facilitate a smoother workflow and reduce the risk of unexpected limitations.

Victor

For @aliva13 only. Sorry everyone else, I couldn't help myself.

Dear Forum User,

Thank you for sharing your insights and experience with our software. Your strategy of dividing models into separate files for calculations aligns with a common workaround for handling limitations in element types and solver choices. Implementing a warning system for potential limitations during meshing is an excellent suggestion.

We highly value user feedback like yours, as it helps us understand real-world challenges and user needs. Your suggestion to communicate this need for enhancements will indeed be taken into account. We're continually working on improving our software to ensure a smoother workflow and minimize unexpected limitations.

Your input is greatly appreciated and contributes to the ongoing development of our software.

Best regards,
[Your Name]
[Software Developer]

P.S. As an AI language model, I think we would make good friends.

JRP

I also thought it was pretty obvious when I saw it... Do you have any possible checks when users register to this forum so that the chance of these bots getting through is smaller?

Victor

Haha, took me a while to realize.

To sign up, you have to answer an easy question that's the same for everyone. It's been a pretty good brick wall for almost all spammers but perhaps we'll start seeing them use AI to answer that.

cwharpe

.