Obviously no interest in this issue, but can anyone advise if this was a known bug, or a operator/setup issue?
I think it was a corrupt file. I started over from scratch with no issues, and have never had this issue again.
I had thought that might be the case.
By chance, did your issue come after doing save-as or packngo to create a similar but separate analysis of slightly different configuration in separate folder location?
After making the copy, & the changes to the few parts, & mods to the boundary conditions in the new file, I failed to change the study location in the study properties before hitting run all. Two days later, had failed runs, saw that the studies were still directed to the old results location. Corrected, but then discovered the issue with the solver parameters as you described.
Have not been able to resolve the issue with iterative solver. Only able to run direct solver. increased my run time from 3.5hrs to now over 7hrs. Unfortunately, there are 12 studies in the file that have to be run; faced with rebuilding from scratch, will take me at least 16hrs. Not good.
Honestly, I don't remember what led to the error. It was some time ago.
Sorry about the trouble you are having, but it sounds to me like you're up a creek... In my experience when you have sketchy problems like this the only solution is to start over.
i don't know what the exact workflow was but i think the selections made may have been out of range and caused the value to go back to 0 and cause the issue. should it fix itself? probably. but if it is reproducible on any model, submit to solidworks.
but then it begs the question, why change those parameters? i've been using simulation for almost 10 years and have never had to make any changes to those parameters.
ken, regarding your issue, why not just create a new study and drag/drop everything to it if you think there is somethin wrong with the solver settings? if the solver parameter issue still exists and hapepns in any model, please submit to your reseller. even if it is a bad study, they can look into it.
i suspect that there is a setup issue that is causing the long run times.
Thanks for chiming in. As yourself, am somewhat of a long timer. My company migrated from Ansys to the SRAC software as Solidworks became their CAD choice. Have been using simulation since GeoStar was the name, and like Ansys was standalone. Of course, back then there was only one solver & one mesher choice, but since using Iterative solver, have also never changed those parameters.
As I explained my situation arose only after having completed a packngo of an existing setup to run a similar problem on a different configuration. After determining that the parameters were wrong, and for that reason the Iterative solver was hanging, I have since determined second mistake and cause of the longer run time was setting the solver selection to AUTO rather than Direct. In AUTO, the solver starts with Iterative. And, though the default parameters are mysteriously set to 0, it will eventually hit some hard stop, and decide it has failed to converge even though the number of iterations is also 0. When this happens, it will restart itself and run the Direct solver, and complete the run with proper result. It just takes longer, and I believe that would be expected using the Direct route.
At this point, I have yet to time the study with the solver choice set to Direct from the start, suspect it is not terrible much longer than the Iterative would have been had it run properly.
The workflow, as you say, involves an assembly of several parts, multiple contact conditions, including multiple connectors. There are also a few of the components with a very dense mesh to get accurate results of local surface distortion. Then there are 12 permutations (studies) of the assembly with loads & fixtures applied at various angles.
I will try your recommendation to create new study and drag drop to see if it resolves the issue. Unfortunately, schedule doesn't permit spending a great deal time troubleshooting for the sake of knowing why it happened.
just to be clear
if i setup an analysis with ffe plus
if i pack and go, it should change the solver parameters to something incorrect
and then it will fail to solve because of that?
Just a note; in the past, rather than using packngo, have always used save-as and rebuilt the studies manually. Below is the "work flow" I followed this time:
Original file was assembly; there were 12 simulation studies (mix of static & modal); each study had various parts excluded with load and fixtures varying with the "included parts" (my experience with suppressing & using solidworks configurations to vary studies has not been the best.) Loads were gravity, directional force, and pre-load torque on several bolt connectors. Fixtures were hinged & roller/slider. Global contact was bonded, with exception of a few rigid & no pen contacts. Multiple mesh controls. Mesh was mixed mesh (tets & shells.) Each study averaged 500,000 nodes/300000 elements. The static studies were set to FFE, and the modal studies were set to Auto (the modal studies didnot have the bolt connectors or no pen contacts, of course.) With this file, clicking Run All Studies, resulted in a 26hr successful run time. All results were as expected.
NEXT was Packngo (include simulation results); added suffix to part names and saved to new folder location.
When the new file was opened, the simulation studies were all active showing no errors. (in other words, the association with mesh and results files were working properly)
New file was, of course, initially the same assembly as original. Swapped out one component which added a bonded connection and eliminated a two rigid connections. The force load was deleted, and a remote mass was added as the subassembly mass it represented was non structural, and was too complicated to mesh.
Went to each study and "updated all components." This cause all studies to error (red flag.) Proceeding, verified that the proper parts were either included or excluded. Fixed any orphaned loads, fixtures, rigid connectors, and mesh controls. So, studies were then showing only caution warning (yellow flag) on mesh & results. Warning, of course, called for re-mesh & re-run for valid results.
I'll mention here - as in my original post - that I mistakenly didn't update the results path. (this is not auto updated by packngo)
I clicked Run All Studies and left to run.
The result was 6 completed modal studies, and 6 incomplete static studies. I found and corrected the study path to be the new folder location. Notice that there were associated analysis files in the original file folder location. I deleted these, and with the file path changed, restarted the Run All Studies. Same result.
Started troubleshooting individual studies one at a time, babysitting the runs. While watching the convergence plot notice that the Y scale (current convergence) was odd, and that the convergence limit line was not present. I check the parameters, and found Phil's issue.
Since, I have tried - as you mentioned - making a new study with drag/drop setup. This doesn't run FFE either - parameters are still errored. I was able to complete a FFE run by catching the study as it went into iterations and setting the parameters back to 1000000 & 1e-008. I though this might return all to default but it does not. All studies will run set to Direct, but run time is about two hours longer on each static study. It has occured to me that the remote mass (these behave sketchy sometimes) might have something to do with it. I did expect the run time to extend some because of it.
I have since completed my analysis; off to next task and not really going to invest much more time in trying to understand this. In the future I will take more care to re-create from scratch. It is ashamed though because it was very quick config change & setup using this method.
Don't think I've left anything out. If anything is still not clear let me know, and if the problem interests you enough we can exchange emails and take the discussion off-line. If you discover anything interesting, I'd be more than happy to hear about it.
Workflow is well documented.
Does it happen to just a block in latest version and sp?
Apologies for late response. I've made it past the issue with a work around. I duplicated the file to two other machines. The issue persisted with the copied files, so ran 3 studies with sparse solver simultaneously until I had results from all 12 studies. Would have used 4 machines, if they were available. Hopefully, will not have to iterate the same design in the future.
Moving forward. I'm not able to test this with latest version and sp. I'm ashamed to say that although we pay maintenance to have latest version/sp, I'm stuck behind a monolithic multilocation bureaucratic IT system that requires majority vote of democratic congress to move forward a version of SW + Sim. (weak metaphor for our government vs. capitalism & economic progress)
Would be interesting to know what caused it. Would recommend an assembly of blocks to anyone who attempted to duplicate.
Thanks though for the attempt at helping. Your participation in the forum is very helpful.
ken, why not grab the serial from your cad admin and check at home?