The fact taht meshing takes a solver license has been part of CFdesign for many years.
This isn't something that Autodesk employed when we were acquired.
I understand, and hence I mentioned that this may have been adopted as a legacy practice from BRN's CFDesign. I have no doubt that all CFD engineers who have worked on CFDesign/SimCFD would have sulked on this limitation when they were faced with it. Change for good is always a welcome. I hope you are able to see the point
If this is something you'd like to see changed, I would recommend you logging an Enhancement Request on IdeaStation (forum thread sticky post has the link to this), as this will allow you to log what you'd like and allow for other users to vote on existing ideas to help promote their priority.
I have already done that as soon as I posted the earlier post, since that seems to be the only platform to voice this concern out.
So from what you've stated the bulk of the issues comes from when you do not touch any of the jobs and they finish on their own?
Mostly, yes. Probably, it may be because only the untouched queue is long. But then, I gave up on causality on this!
Do some of those jobs sit in a Finished state for a while before the analysis is opened and the data is then copied back to the local machine?
This depends on the holidays etc. You can imagine that at a time, only one scenario is open so only one job gets copied back. All the scenarios in same cfdst or other cfdst sit idle until they are opened. Typically, the larger queues get executed only on holidays, ie, weekends and bank holidays etc. Because, on day-to-day basis, I prefer to open the run scenarios and get the results copied, lest - the inconsistency in the cluster integration would start affecting us.
Hello, I'm having the exact problem that you listed here. Based on how it was written, I'm guessing that there's a solution?
Essentially, I've got runs that appear on the remote solver as having finished after a night of running, but they don't write properly back on my laptop. This only happens overnight when I have disconnected the laptop from the network where the remote solver lives.
Is there a solution? I'm stuck on 2013 for a little while for info.
7) If you do not close the interface do the jobs more consistently come back?
We've consistently been fighting this and similar issues with remote solving for the past few revisions of the software. It usually falls into a couple categories:
1) User kicks the analysis over to the remote PC to solve, closes the interface. The solution runs and states it is finished, when the user reconnects the simulation with results don't pull back to the user's PC. Has happened a couple times when the user leaves the UI open, but happens more often when they close the interface and use the simulation monitor tool to watch for when their sim finishes as they do other work. The same simulation will run and complete when run locally.
2) Queuing function fails to hand off to the next simulation. Example, a stack of 6 simulation are queued (from one user or from a couple of users). A simulation in the queue will finish, but the next one in the sequence fails to start. Only solution we've found is to stop and start the solution service which flushes out the queue forcing everyone to resubmit.
We have one user that uses Sim360 for this and rarely runs into a problem - usually an issue with how the simulation was set up, geometry or such. The problem is our other uses have to use the in-house setup - they continue to have sporadic issues with remote solving to the point they sometimes choose just to avoid going remote and run locally. In our case we're just remote solving to a single PC, not a cluster. We do it to allow multi-user queuing using a single solver license and to avoid crippling the user's PC as the run completes.
I did some fairly extensive testing to track the exact problem regarding 1) in your example above. I've reported the exact bug to Autodesk so they know about it now. Perhaps it'll be solved in 2015?
Specifically, the problem relates to killing the process “SimCFDserver 2014”. This can be either through shutting down windows or by using task manager; both give the exact same result.
My team now remote login to the CFD solver machine. This solves the problem. It might improve the queing too?
I second your view, this is how we do it as well. Remote logging into headnode of cluster and then queuing is generally more robust. But we have two licences and of course would like to run two simulations at any time. We generally have several scenaros in one Design Study, but have to queue serially since you can't parallely run two scenarios with the same solver (Technically you can by using half no. of cores etc, but it is the least robust approach in my experience). So currently I have to create a copy of of the same simulation file locally and queue half of the scenarios locally while cluster is solving the other half of the queue. So, there are two simulation files generally for a project.
To mitigate this, I was thinking of experimenting a little. If I could map my local machine as remote solver for cluster's headnode, then while half the scenarios are queued on the cluster (run through its headnode by remote logging), I can run other scenarios as well. So basically, my local PC (a decent configuration so won't buckle) will be a remote solver to my cluster's headnode! I know it's crazy. Have you tried this workaround ever?
I also welcome Autodesk personnel to comment on this approach.
A soultion so simple?!?
More seriously, it's not a method that we could really use here. I'd be interested to hear if you ever get it working though!
This is a good example where in your case we had very specific workflows that allowed us to consistently repeat what you were seeing and be able to present this to our development team. It is something that is actively being investigated.
Any thoughts on the method I mentioned (using local machine as a remote solver for cluster)? Not the most elegant approach, nor do I know if it will work consistently...
There shouldnt be anything wrong with this procedure. Obviously once you remote solve from the Remote machine to your local machine you will want to avoid shutting down your local machine while the run is occuring to avoid killing the solution prematurely.