Solidworks Simulation and PDM

[SPerman]

I've been working on this model off and on for several days. I made some changes this morning, and when I tried to run stress analysis on this part I get this error message:

I've had this happen in the past, and the solution has been to save the part outside of PDM, do my work, and then incorporate those changes back into the part stored in PDM.

Does anyone have any suggestions on how to work on models stored in PDM while running simulations?

[JSculley]

Best guess, this is some sort of file system timing problem. The Fortran runtime is creating a file in the vault. PDM sees this and then grabs control of the file to officially add it to the vault. While this is going on, Fortran tries to open or write to the file but can't because PDM still has the file lock.

Easiest fix is to tell Simulation to put the results folder outside the vault.

[bnemec]

Our process slowly evolved over several years to copy out the needed file to a location on local disk, preferably appending version number to end of file name(s). Reasons:
- There's typically enough editing needed to model to do the sim that is not what we want in the production model that we need a copy anyway. Managing it with versions became more hassle than worth and branch-merge would never be merged.
- Cannot give concrete evidence, but the PDM client service doesn't seem to keep up adding files to the vault at the pace sim can create them. We found little use in letting all the sim files be in a vault path and get the feeling that doing sim work from vault path might be a hinderance. We even set up a folder, category and workflow for sim files in vault; we just didn't see any benefit to putting them in vault.

[SPerman]

In this case it is tied to a single study. I was able to copy a similar study and it would run. If I tried to rename that study to the original problematic study, it crashed again.

I usually don't do simulation work with the files still in PDM. I thought I would see if I could get away with it, but you have confirmed that the best workflow is to do this outside of PDM.

[JSculley]

In this case it is tied to a single study. I was able to copy a similar study and it would run. If I tried to rename that study to the original problematic study, it crashed again.

I usually don't do simulation work with the files still in PDM. I thought I would see if I could get away with it, but you have confirmed that the best workflow is to do this outside of PDM.

What is the name of the study that behaved badly? It's interesting to me that the crash dialog shows that the file name is C:\.CFG, which doesn't make sense, since it should be C:\<vault_location>\<study name>.cfg.

Perhaps Fortran doesn't like something about that original study name.

[SPerman]

The name was "Down" and I ran it successfully for a couple of days before it started displaying this error. Fortunately "Up" was the same study with the force reversed, so I copied it, renamed the copy Down A, changed the direction of the force and was able to continue. If I tried to change the name from DownX to Down, it failed again.

[JSculley]

Nothing unusual about that name. Is there a Down.CFG file in the vault folder where the simulation files are being placed? If so, is it actually in the vault or is it a local file? If it's truly in the vault, is the read-only attribute set, even though the file is checked out?

[SPerman]

There is a .cfg file for "Down" and it is the only CFG file associated with that part.

image.png (11.2 KiB) Viewed 2047 times

Down, Down 2, Down3, Up, Up 2 and Up 3 were the original studies. Down A and Down Redo are from me diagnosing this problem.

Yes, on the read only attribute.

Thanks for your help with this.

[JSculley]

If the file is checked out, the read-only flag should not be checked. I would uncheck it and see if the problem goes away.

[bnemec]

If the file is checked out, the read-only flag should not be checked. I would uncheck it and see if the problem goes away.

Nice catch. I used to see this a lot from a few users who insisted on using vault view to do PDM stuff (like check out) while files are open in Solidworks. I would not have guessed it in this scenario.

[SPerman]

I didn't set the file to read only. That was something that happened by itself.

[JSculley]

So, I had a simulation to run so I thought I would play around with this. My simulations did not generate a .CFG file, but apparently, that file is only generated if you use the FFEPlus solver. I switched to that solver and still didn't see a .cfg file. However, all the other files that were generated were all local files that did not get added to the vault:

Did the .CFG file get added to the vault for you automatically? Or did you manually add it via right click....Ad File to Vault? According to the SW KnowledgeBase the file is a temporary file:

=================================
Question
When I run a SOLIDWORKS® Simulation study, why does the software generate a *.CFG file in the results folder?
Answer
The *.CFG file is a temporary file that the FFEPlus iterative solver generates when solving a Static study. This is a temporary file necessary for the solving processes.

After the solution is complete, SOLIDOWRKS® Simulation software no longer requires this file.
===================================

I would expect it to show up as a local file and disappear either when the solve is complete or when the Simulation add-in is turned off (or SW is shut down). Most of the the local files I listed above disappear when I turn off the Simulation add-in. A few are left behind:

There is an SPR about that issue:

==============================
SPR1067866---After running static study and closing file, some solver files are not deleted (.BD2, .MFC, .BDF, .FRC, and potentially more)
=============================

[SPerman]

I did a bit of PDM cleanup Friday morning. I had finished a project that needed parts / assemblies checked in and released. I accidentally checked in some files from this project at the same time, but my PDM searches are setup to only report *.SLD* files. The only way the file would have been checked in is if it came along for the ride when I checked in the part. BUT, I did FE on this part for several hours on Friday afternoon and there weren't any issues. I did more work on Monday without any problems. It was only Tuesday morning that this issue raised it's ugly head, several days after I did any checking in and releasing in SW PDM. There were several reboots along the way. I'm sure there was at least one forced shutdown / crash of SW while running simulation, but the timing doesn't align with the problem.

I'm writing it off as Solidworks being Solidworks. Like today when I fired up the program and my layout had changed.

[bnemec]

Would adding those temporary file types to the "never add these file types" list in user/group settings help?

Is PDM adding it to vault but then the SW cannot delete them per PDM permissions? Then the file checked in due to relations, but then when pdm service tried to remove the read only flag on local file upon checkout the file was already "locked by another process"?

[SPerman]

I wasn't aware of that setting. I will give that a try and see.