Has anyone else found while running a Non-Linear analysis with contacts that Creo Parametric Simulate loses the network license?
The license server needs to be on a separate computer on the network..
With the license server installed on the workstation performing the analysis the error message goes away and the analysis appears to run up to 20 minutes faster.
Have any of you seen this message?
Solved! Go to Solution.
I would think it's not the type of analysis you are running, but rather how long that analysis is taking. Whenever I've run very long simulations, the licenses are continually being "lost" and then "found". I think it has to do with the fact that even though the CPUs are pounding away on the calculations, if Creo deems itself as "idle" due to a lack of mouse movement or menu picks, it releases the license back to the "license pasture". It then re-acquires it when the simulation does something that requires a license, etc. It probably does slow everything down just from the network traffic.
I've also found that if I have the disk space available, running the big cases is much faster if I have the files on my local machine, rather than on a shared server, 'cause the massive amount of data read/write operations is not going to the server.
I think Kenneth broadly has it right.
Worth being aware though that the Mechanica solver uses its own licence (typically MECSTRUCENG), which is separate to both MECSTRUCUI (when you've entered Applications -> Simulate) and the base Creo licence. (Note that you can actually close Creo completely, and the analysis will continue running.) So it's not Creo (xtop.exe) that's losing the licence, but Mechanica (msengine.exe). Might be worth reviewing the licence timeout settings on the server?
And absolutely agree that Mechanica temporary (and results) files should be on a local hard drive, not across the network - copy the results to a network location afterwards, if you need to. Although you're getting about 1.5:1 CPU time to elapsed time which looks respectable, so you're probably already doing that.
You are correct, temp files are being written to the workstation that's running the analysis and it's a Solid State Drive.
I´ve seen that a couple of times, I use Simulate 3.0 Academic Version. I have the license installed on the same workstation, for me It doesn´t affect the simulation. It happens after several hours after you started the analysis or sometimes randomly.
I have tested with the same assembly on Creo 2, Creo 3, and Creo 4 with all giving me the same lost license message.
Working with PTC top level tech support they set me up with a temporary license so we could install a temporary flex 3 license server on my local workstation. When Creo using the local flex 3 license server on my work station the error message go's away and the analysis runs faster.
I believe they have a issue with msengine dropping the license during certain analysis.
Creo it's self appears to not lose the license.
PCT feels it's an issue with our network setup.
I believe it's related to how Simulate communicates with the flex 3 license server.
How are you getting your license?
Are you using a Flexnet license server (flex 3) on a different computer than the one that's running the analysis?
FYI, There are no issues with a dedicated license from the testing I have done so far.
PTC is probably right - there's a network problem. If it was fundamental to Simulate, then everyone would have the same problem. The cause of this particular problem is likely to be in the frequency with which Simulate checks for license validity and you may have a time-out problem that causes the connection to be dropped for inactivity. By the time the network re-establishes the connection, it's been too long and Simulate assumes it can't communicate with the server and drops the license or vice-versa and the license server can't see the workstation.
If you look at the server side you can see if the server thinks the license has been dropped at the same time.
To check this out, set up a script that pings the license server at regular intervals to keep the connection current. I'd start at one second intervals and increase until it fails again.
I'm inclined to think it's failing from the workstation end because if it was failing to communicate it would stall the analysis while it retried the connection, causing the job to stop, and slowing overall progress. You can look at the process graph to see if that is happening.
Fixing a network problem is a tough thing. There are a lot of plug-and-pray networks out there with admins who aren't equipped to debug such problems and without capital funds to replace them if the admin can't prove them faulty.
There's no chance wi-fi and ethernet are both connected at the same time is there?
We have previously looked at the server and logs along with allowing PTC to look at the server real time while I was running the analysis. They pinged the server and found nothing out of the norm. We had I believe 4 PTC engineers on the phone at that time.
They found nothing out of the ordinary and their conclusion at that time was that it must be firewall or antivirus related. We have Proven that the firewall not the issue
and have added all of the exclusions that PTC recommended.
My work station's connected by Ethernet with no Wi-Fi hardware installed. Workstation's on a internal local network with the server.
So now we are running out of options to try.
I have found that others have seen this issue but were not aware of it till I pointed it out to them and they looked closer at the analysis logs.
I will take a look at the process graph again and see if I see anything again. I think that might be a hard to decipher as it could be stopping to hand off/write data to reports?
I will also try to get a copy of Creo 2 M080 but this might be hard as we are currently off maintenance. I do believe our license server will support it as I can run Wildfire
and have reproduced the issue with wildfire m220 also.
You probably need to see if you can get the license manager company on the phone through PTC. I think PTC still buys it from a third party and may not have the tools required to see why the product thinks there's a problem.
Also look for a network analysis tool. Ethernet is very robust in the face of significant electrical problems and this may be seen only at the transmission layer.
(Recently I saw a nice write-up from a guy on a support desk for a bunch of widely distributed sites. He started getting calls about network problems and noted that no site called just once and that as time passed they called more frequently. Unable to uncover the problem over the phone he pressed to make a visit. It was pretty obvious once he arrived. They had put the new network wiring punch-downs in the only unused wall space in the office - the janitor's closet, just above the sink. Reliable at first, the ammonia and moisture would corrode the contacts and just get worse. The same team had done all of their facilities the same way.)
At least you don't have to pass dongles around.
This was one of the first things we looked at with the PTC support engineers. When we last talked with PTC they thought the settings we are currently using should work, but they haven't fixed the issue we are having. Current settings are:
Any other ideas?
TIMEOUTALL option is not active in your ptc.opt file (it's line is recognized as a comment). Therefore I guess that timeout for Creo Simulate licenses is 1200 s (minimum, i.e. 20 minutes).
Set TIMEOUTALL 7200 and run Creo Simulate analysis.
We have tried 7200, 2400 and many others. After talking to PCT it wss decided to comment it out so simulate wouldn't time out and drop the license.
I still need to do some more testing. But it looks like the order that the license servers are specified make a difference in the .psf files. Changing the order of how the servers are called out (putting the server with the Simulate licenses first) made the difference from what I can see so far.