from what i saw of your error message details, it looks like you might have a problem with the contact setup. if you can try a simple model with just one part and fixed constraint, it might help.
the environment windows are for windows. they changed how you access them. it's rather difficult now. you go to settings, system, about, advanced system settings, then click environment variables. scroll through and see if some have already been created. you can modify them if needed and also add new ones. also, you have to close the popup for the environment variables and the system properties, for the changes to take effect. since the mods i showed are just for ccx, you don't have to close and restart mecway.
note that the mods are put in the system variables area, rather than the user variables area.
from what i can tell, the cyclic symmetry seems fine. where i'm having problems is trying to match a full rotor's results to the cyclic results. there doesn't seem to be a way to do that. i end up just modeling one blade because that gives me the results i need. however, some people need full rotor results. if you don't use cyclic symmetry, then i'm not sure how to go about it. what i get is multiple results for the same mode (when doing the full rotor). maybe if i ran like 100 or more modes, it might start showing some of the cyclic modes. but it gets really annoying having to sift through all the results. what would be nice is if it didn't keep repeating modes. maybe there's a reason that's not possible. full rotors isn't something i have experience with. other than test models to compare to the cyclic results. in the old days, it was difficult just to get one blade running. things have come a long way. we had to do linear static stress with a beam model and one blade modal analysis with a shell model. that was state of the art back then. only nasa had access to nastran, for awhile. then industry finally got it. however, not many had it or used it.
for what i was seeing, any model would work. just do a cyclic model and make a full rotor equivalent. then say do 6 modes for the cyclic model. now try to get the same six modes from the full rotor. that's where i was having issues. the other problem for me was, there was no way to do a real model. i could only do very small models. the cyclic feature is nice, but not usable for anything real. at least on my laptop.
on the old model i was re-running, i increased the mesh density some, so it's taking a long time to solve. it has eight blades. on the full rotor i get the same mode for each of the eight blades. so i guess the full rotor would be the (number of blades ) x (the number of desired modes). not 100% sure though. on the cyclic model. i requested 6 modes but it returns 30. so for the full rotor, i would probably have to try 8 * 30. which equals, ouch, for me. i might try it but with a crappier mesh. so i don't melt my laptop.
I was talking to Victor about the ccx i4 vs i8 thing and he brought up an interesting point. I think most CPUs have 64bit bus widths. So you could fit twice the integers per clock with i4. If you have AVX-512, it's architecture dependent implementations. But that could be up to four i*4 per clock. So the slow down of going to i8 may be something unavoidable. It could be that I've never seen it because my codes don't handle the huge amounts of data that FEA does. However, when I used ANSYS, it was always very very fast and could easily go out of core. I use to run it that way all the time. Back then, having 16gb of memory meant you were a super user. Everyone had 4gb. You had to justify to management as to why you needed 16gb, lol. It was also crazy expensive to get a computer with 16gb of memory. So I still think there is something behind the scenes that is amiss with ccx and giving no results and also just being really slow. Just not exactly sure what it is. On the ccx forum; one user went through great lengths, to debug why he was getting no results, and found there was a race condition with mult-thread. My experience has been I can get no results on any ccx analysis type, not just the analysis type that the user on the ccx forum was having. Or the analysis mentioned in this post. It happens for me when trying to solve models that are too big for the amount of physical memory. Perhaps, that causes a race condition, in a round about way.
there are still some variables missing. the omp_num_threads is the most important one that i see. just make sure you get them all in there. as far as no results, i can't say for sure. i would def do some test models first though.
i just got my old comparison done and the results match. it works better with cyclic sym. i can get all the modes. for the full rotor it's repeating the same mode based on blade count. so it becomes too hard to run them all. my computer can't handle it. i was able to match the first six. for the full rotor i had to run 8 blades * 6 modes = 48 modes requested. with cyc sym there is a formula based on nodal diameters. if you request 6 you get 30, for an 8 blade model. i made a calculator to do the math on it.
so a few things i mentioned previously, that i'm seeing again. i think you are going to have model size issues. i noticed for nonlinear my chart works. but for modal it's about a 3rd less. so the memory requirement is higher for modal analysis than nonlinear static, it seems. meaning i can solve about 1million nodes for nl static. but for modal it drops to about 400,000 nodes. then the issue of whirling modes and repeated modes etc. mecway/ccx just aren't very good in this arena. luckily for me, i only have to do single blades. i feel like you are going to have a lot of problems.
since you keep getting no results, i would really do a simple case of a fixed rod or something and apply centrifugal force. do a prestressed modal analysis. see if you get results. make the mesh big enough to check core usage and memory limits, via the windows task manager. you should be able to get about a 300,000 test model through and be below your memory limits. if you use omp_num_threads to use 4 or 8 cores. check to make sure it reaches that. it will only hit the max occasionally through the solve. but you want to check that it's all working. by knowing your node count max, it helps you save time by avoiding failed outcomes. once you got it working and know the limits, then go back to the model that isn't working.
I added all system variables per your pic and ran a simple model for static solution with air loading and fixed constraint. Same results no solution. Is there anything that I’m missing.
I'm stumped. not sure what's going on. you can try uninstalling and reinstalling mecway. it won't affect all the customization you did yesterday. but I'm really not sure.
I haven't really been following this thread but a couple of thoughts:
As I understand it, i8 allows the solver to use more than ~32 GB. Since you only have 16 GB, Windows would need to use disk swapping which will either completely destroy performance or not work.
What I think would work here is MKL out-of-core (OOC) mode. You have to compile CCX from the source included with Mecway which includes a patch to enable OOC mode.
Can you use the internal solver instead? That does OOC out of the box. At least try a similar model with that to see if MKL OOC can work there.
@hooshsim can't use cyclic symmetry because his geometry isn't cyclic symmetric. so he has to do a full rotor. i'm not sure why he is getting no results at this point. it's different than why am not getting results.
@victor on one cyclic symmetric test model, mecway gives an error because the number of nodes aren't the same on the master and slave surface. ccx seemed to be running but it started going out of core and hung up. the other model will solve with ccx. i haven't tried it with mecway. i'll see if it gives the same error.
@disla yes that is a good tip for results view speedup. but it sort of defeats the whole purpose. you can't see the full disk modes properly, when using that option. i have used that option though, for some tests. thanks for mentioning it again.
@victor you may need to help @hooshsim with his issue. he seems to be having no results return for an unknown reason. one model seemed to indicate he had contact issues. however, he also stated that a different test model didn't run either. he did mention that when he uses mecway internal, he gets results. so it seems limited to ccx. i tried to walk him through how i set things up. however, that still didn't work for him. thus, i'm completely stumped on this one.
@victor that's a fascinating insight into i*8. i really don't want to compile ccx. so i'm ok living with the in core limitation. good to know there is a work around though.
update;
my other cyclic symmetric test model won't run with mecway internal error. it gives a different error. regarding incompatible constraints.
¿Would it be possible to see that model?. It's almost impossible to help without it . It could be a completely random or even a simple error. Maybe in private @hooshsim.? @prop_design?
It almost seems we are talking about different models and problems at the same time.
i can send you links to models but i've got everything worked out on my end. it's @hooshsim who is having issues. i don't want to confuse this thread up any more than it is, lol.
The full fan model has several bonded contacts between nylon blades and metal inserts. Internal can not used because of tie feature. Another reason is as @prop_design pointed out in earlier post a blade modal does not match full rotor frequencies.
I’m willing to try to compile ccx from the source included with Mecway if someone gives me detailed guidance on how to compile, etc…not an expert in Mecway
Thank you, Victor. Ran my blade sector successfully using Internal with TIE off. First mode was computed as 57Hz vs 61Hz using CCX. CCX is much faster than Internal. I will submit the full fan model shortly. Fingers crossed.
@Victor. I have submitted my full fan model with 453,000 nodes for modal analysis using Internal solver. It’s been more than two hours that solver is running on 16 GB ram. (I think it’s running see attached). Is this normal or something is wrong? Thanks
Comments
the environment windows are for windows. they changed how you access them. it's rather difficult now. you go to settings, system, about, advanced system settings, then click environment variables. scroll through and see if some have already been created. you can modify them if needed and also add new ones. also, you have to close the popup for the environment variables and the system properties, for the changes to take effect. since the mods i showed are just for ccx, you don't have to close and restart mecway.
note that the mods are put in the system variables area, rather than the user variables area.
from what i can tell, the cyclic symmetry seems fine. where i'm having problems is trying to match a full rotor's results to the cyclic results. there doesn't seem to be a way to do that. i end up just modeling one blade because that gives me the results i need. however, some people need full rotor results. if you don't use cyclic symmetry, then i'm not sure how to go about it. what i get is multiple results for the same mode (when doing the full rotor). maybe if i ran like 100 or more modes, it might start showing some of the cyclic modes. but it gets really annoying having to sift through all the results. what would be nice is if it didn't keep repeating modes. maybe there's a reason that's not possible. full rotors isn't something i have experience with. other than test models to compare to the cyclic results. in the old days, it was difficult just to get one blade running. things have come a long way. we had to do linear static stress with a beam model and one blade modal analysis with a shell model. that was state of the art back then. only nasa had access to nastran, for awhile. then industry finally got it. however, not many had it or used it.
for what i was seeing, any model would work. just do a cyclic model and make a full rotor equivalent. then say do 6 modes for the cyclic model. now try to get the same six modes from the full rotor. that's where i was having issues. the other problem for me was, there was no way to do a real model. i could only do very small models. the cyclic feature is nice, but not usable for anything real. at least on my laptop.
on the old model i was re-running, i increased the mesh density some, so it's taking a long time to solve. it has eight blades. on the full rotor i get the same mode for each of the eight blades. so i guess the full rotor would be the (number of blades ) x (the number of desired modes). not 100% sure though. on the cyclic model. i requested 6 modes but it returns 30. so for the full rotor, i would probably have to try 8 * 30. which equals, ouch, for me. i might try it but with a crappier mesh. so i don't melt my laptop.
I added two variables to the system environment as highlighted in the attached picture. Still didn't get any results. No error message either.
At this point, I am not worried about anything but to get the big model to run. Thanks
there are still some variables missing. the omp_num_threads is the most important one that i see. just make sure you get them all in there. as far as no results, i can't say for sure. i would def do some test models first though.
i just got my old comparison done and the results match. it works better with cyclic sym. i can get all the modes. for the full rotor it's repeating the same mode based on blade count. so it becomes too hard to run them all. my computer can't handle it. i was able to match the first six. for the full rotor i had to run 8 blades * 6 modes = 48 modes requested. with cyc sym there is a formula based on nodal diameters. if you request 6 you get 30, for an 8 blade model. i made a calculator to do the math on it.
so a few things i mentioned previously, that i'm seeing again. i think you are going to have model size issues. i noticed for nonlinear my chart works. but for modal it's about a 3rd less. so the memory requirement is higher for modal analysis than nonlinear static, it seems. meaning i can solve about 1million nodes for nl static. but for modal it drops to about 400,000 nodes. then the issue of whirling modes and repeated modes etc. mecway/ccx just aren't very good in this arena. luckily for me, i only have to do single blades. i feel like you are going to have a lot of problems.
since you keep getting no results, i would really do a simple case of a fixed rod or something and apply centrifugal force. do a prestressed modal analysis. see if you get results. make the mesh big enough to check core usage and memory limits, via the windows task manager. you should be able to get about a 300,000 test model through and be below your memory limits. if you use omp_num_threads to use 4 or 8 cores. check to make sure it reaches that. it will only hit the max occasionally through the solve. but you want to check that it's all working. by knowing your node count max, it helps you save time by avoiding failed outcomes. once you got it working and know the limits, then go back to the model that isn't working.
I added all system variables per your pic and ran a simple model for static solution with air loading and fixed constraint. Same results no solution. Is there anything that I’m missing.
As I understand it, i8 allows the solver to use more than ~32 GB. Since you only have 16 GB, Windows would need to use disk swapping which will either completely destroy performance or not work.
What I think would work here is MKL out-of-core (OOC) mode. You have to compile CCX from the source included with Mecway which includes a patch to enable OOC mode.
Can you use the internal solver instead? That does OOC out of the box. At least try a similar model with that to see if MKL OOC can work there.
for @victor and @disla
@hooshsim can't use cyclic symmetry because his geometry isn't cyclic symmetric. so he has to do a full rotor. i'm not sure why he is getting no results at this point. it's different than why am not getting results.
@victor on one cyclic symmetric test model, mecway gives an error because the number of nodes aren't the same on the master and slave surface. ccx seemed to be running but it started going out of core and hung up. the other model will solve with ccx. i haven't tried it with mecway. i'll see if it gives the same error.
@disla yes that is a good tip for results view speedup. but it sort of defeats the whole purpose. you can't see the full disk modes properly, when using that option. i have used that option though, for some tests. thanks for mentioning it again.
@victor you may need to help @hooshsim with his issue. he seems to be having no results return for an unknown reason. one model seemed to indicate he had contact issues. however, he also stated that a different test model didn't run either. he did mention that when he uses mecway internal, he gets results. so it seems limited to ccx. i tried to walk him through how i set things up. however, that still didn't work for him. thus, i'm completely stumped on this one.
@victor that's a fascinating insight into i*8. i really don't want to compile ccx. so i'm ok living with the in core limitation. good to know there is a work around though.
update;
my other cyclic symmetric test model won't run with mecway internal error. it gives a different error. regarding incompatible constraints.
It almost seems we are talking about different models and problems at the same time.
i can send you links to models but i've got everything worked out on my end. it's @hooshsim who is having issues. i don't want to confuse this thread up any more than it is, lol.
I’m willing to try to compile ccx from the source included with Mecway if someone gives me detailed guidance on how to compile, etc…not an expert in Mecway
Step by step instructions are included with the source code in Mecway's installation folder under ccx/ccx_win64_mkl_pardiso_source_2.19.zip
BTY, solver finished successfully after 2.5 hrs.
Thanks to all involved with this thread especially prop_design