## Some Tips on Configuring RSM as a User

If you’re not familiar with it, RSM is the ANSYS Remote Solve Manager.  In short, it allows you to submit solutions from various ANSYS tools so they can be solved remotely, such as on a compute cluster, remote number cruncher, or perhaps just another computer that isn’t being used very much.  Note that there is no additional licensing or installation is required (other than perhaps ANSYS HPC licensing to take advantage of multiple cores).  RSM is installed automatically when ANSYS is installed; it just needs to be configured to be activated.

In version 14.5 and 15.0, there is a nicely documented Setup Wizard that helps with the setup and configuration of RSM on compute servers.  This setup wizard as well as the rest of the RSM documentation in the ANSYS Help does a great job of explaining RSM and what must be done to setup and configure it.  This Focus entry assumes that your crack IT staff has installed RSM on your compute machine(s) and has decided where the Compute Server will be (can be on your local machine or on your ‘number cruncher’ or on a different machine).  So, our focus here is on what needs to be done as a user to send your solutions off to the remote solver using RSM.

As an example, we have RSM 15.0 configured with the Compute Server on a remote computer named cs3a. The first time running RSM, using Start > All Programs > ANSYS 15.0 > Remote Solve Manager > RSM 15.0, we get the window shown here:

Notice that it only shows our local machine (My Computer) and nothing about the actual remote computer on which we want to solve.

Therefore, we need to add the information on our cluster node which contains the compute server.

To do this, click on Tools > Options.  This is the resulting window.  Notice the Add button at lower left is grayed out:

What it’s waiting for us to do is type in the name of our desired remote computer, like this:

Now that a new name has been typed in the Name field, the Add button is active.  After clicking Add, we get this:

After clicking OK, we will now see that the new remote computer has been added in the RSM window:

The next step is to set your login password for accessing this computer.  Right click on the new hostname in the RSM window in the tree at left, and select Set Password.

If your accounts are fully setup, at this point you can run a test by right clicking on the localhost item in the tree under the remote computer name and selecting Test Server:

If the test is successful, you will see that the test job completed with a green checkmark on the folder icon in the upper right portion of the RSM window:

If your login is not configured properly, you will likely get an error like this one shown below.  Notice that the upper right portion now states that the job has failed and there is a red X rather than a green checkmark on the folder icon.  By clicking on the job in the upper right panel, we can see the job log in the lower right panel.  In this case, it says that the login failed due to an incorrect password.

The fix for the password problem is to ensure that the correct login is being accessed by RSM on the remote computer.  This is done from the RSM window by right clicking on the remote computer name and selecting Accounts.

If your account and/or password are different on the remote computer than they are on your local machine, you will need to establish an alternate account so that RSM knows to use the correct login on the remote computer.  Right click on your account in the Accounts pane, and select Add Alternate Account:

Enter your username and password for the remote computer in the resulting window.  Next, we need to associate that login with localhost on the remote computer.  This is down by checking the localhost box in the Compute Servers pane, like this:

Another problem we have seen is that the user doesn’t have permission for ANSYS to write to the default solve directory on the remote computer.  In that case, the test job log will have an error like this:

This fix in this case is to establish a solve directory manually, first by creating one on the remote computer, if needed, and second by specifying that RSM use that directory rather than the default.  The second step is accomplished in the RSM window via right clicking on the localhost item for the remote computer, then selecting Properties.  On the General tab, you should be able to change the Working Directory Location to User Specified, then enter the desired directory location as shown in the image below.  If that option is greyed out, either your password for the remote machine has not been entered correctly, or you are not part of the admin group on the remote computer.  In the case of the latter, either your RSM administrator has to do it for you, or you have to be granted the admin access.

At this point, if the test server runs have completed successfully you should be ready to try a real solution using RSM.  We’ll use Mechanical to show how it’s done.  In the Mechanical editor, click on Tools > Solve Process Settings.  Here we will need to specify the remote computer and queue we’ll be using for the solution.  Click on the Add Remote button:

In the resulting Rename Solve Process Settings button, type in a name for your remote solve option that makes sense to you.  We called ours RemoteSolve1.  This new option will now show up on the left side of the Solve Process Settings window:

The next step is to type in the name of the Solve Manager over on the right side.  In our case, the Solve Manager is on computer cs3a.  Any queues that are available to RSM for this Solve Manager will show in the Queue field, after a brief period of time to make the connection.  In our case, the only queue is a local queue on cs3a.

We are now ready to solve our Mechanical model remotely, using RSM.  Instead of clicking the Solve button in Mechanical, we will click on the drop down arrow to the right of the solve button.  From the dropdown, we select the remote solve option we created, RemoteSolve1:

Assuming the solution completes with no errors, this job will show up in the RSM window with a status of Finished when it is done.

The final step in this case is to download the results from the remote computer back to the client machine.  In the Mechanical editor, this is done by right clicking on the Solution branch and selecting Get Results as shown below.  Also note that you can monitor a nonlinear solution via Solution Information.  You’ll just need to right click during solution to have a snapshot of the nonlinear diagnostics brought back from the remote computer.

We hope this helps with the setup and utilization of RSM from a user perspective.  There are other options and applications for RSM that we didn’t discuss, but hopefully this is useful for those needing to get ‘over the hump’ in using RSM.

We were pleased to note today that PADT Medical customer Ulthera Inc. filed for an $86M IPO with the SEC. We have truly enjoyed working with this company offer our congratulations to them on reaching this major milestone. You can read about the IPO in the Phoenix Business Journal here. You can also read a case study on some of the work that PADT has done for Ultherea in the past here. Posted in News, PADT Medical | | Leave a comment ## ASU Research Park Celebrates 30 Years How do you turn a political defeat into a big win, you look at your options, decide where you want to go, and you do it. That is what a group of valley visionaries did in the early 1980′s when the state decided that only the University of Arizona could should have an agriculture program. That left Arizona State University with a large working farm that needed to be taken down. They could have sold the land for quick profit. But instead they looked at options that would provide the most long-term benefit to the school, the state, and the local community. The result, thirty years ago, was the ASU Research Park. Located just west of the 101 Loop between Warner and Elliot roads, the Park is now a vibrant and thriving hot-spot of technical innovation and realization. This is not an incubator where people try to be successful in technology, this is where people who are successful with technology come to get stuff done. PADT is pleased to own a building in the Park, the PADT Innovation Center, where our headquarters are located along with three other business that lease space from us. We have found the park to be a supportive place, centrally located, with great facilities for our employees. The event was marked with a breakfast gathering of tenants, Tempe officials, Park board members, and representatives from ASU. Dr. Michael Crow, the President of ASU gave a great speech on how the park in particular helped move ASU towards being a true research university. He stressed that unlike in most places, ASU didn’t plan and study and move slowly. They wanted to become a research university and if you want to be a research university, you need a research park. So they built a research park, and in the end, a very successful one. Some interesting facts about the park: • Home to 49 companies with a total of over 4,500 employees • Generates over$2,000,000 annually for ASU
• Has a \$816,000,000 annual impact on the Arizona economy, generating 11,180 jobs
• 89% of the park is leased, 26 Acres still available
• 1,790,000 sqft of office space, with 350,000 sqft under construction.
The mayor of Tempe, Mark Mitchel, was also on hand to share with the audience the strong impact that the park and ASU have had on the city and how the ASU Research Park is a true university-city initiative. In fact, Mr. Mitchel’s father, Harry Mitchel, was the mayor of Tempe thirty years ago and was one of the visionaries that helped make the park happen.

This aerial view, taken a few months ago, shows the new GoDaddy tech center being built in the lower right hand corner. The PADT innovation center is the upside-down check mark in the upper right corner.  PADT customers ViaSat and Amkor are both starting construction in the park right now.

To learn more, read the official press release: ASU Research Park Celebrates 30 Years – Press Release, or visit the park’s website: asuresearchpark.com.

## NeruoEM’s Featured in Phoenix Business Journal

It’s always nice when a customer gets a mention in the local press. PADT is helping NeruoEM in the development of a “a self-contained head device to prevent and treat Alzheimer’s Disease (AD) with electromagnetic waves.”  Check out the write-up here.

There is not a lot we can say about the project or what we are doing for NeuroEM, but the website and article both give a good overview.

Needless to say, the older we all get, the more desire we have for this device to transition to an approved medical device.

## Getting to know ANSYS – Rigid Body Dynamics (RBD)

This video is an introduction to ANSYS RBD – an add on module to ANSYS Mechanical for analyzing rigid mechanisms.

## Pictures and Reflections from PADT’s 20th Anniversary Party

PADT held our 20th anniversary party at our primary offices in Tempe Arizona on April 10th. Despite the record high temperatures, around 400 people stop by to help us celebrate.  There was good food, good entertainment, and most importantly, good people.

A highlight of the event is that April 10th was proclaimed PADT day in Tempe!  That was an unexpected honor.

The only problem was not enough time to talk with everyone.  If you could not make it, no worries. We have several events planned throughout the year.

Here are some images that we captured:
Most of these pictures were taken by Aaron Moncur from PipelineDesign.

## ACT Extension for a PID Thermostat Controller (PART 2)

(View part one of this series here.)

So, I’ve done a little of this Workbench customization stuff in a past life. My customizations involved lots of Jscript, some APDL, sweat and tears. I literally would bang my head against Eric Miller’s office door jamb wondering (sometimes out loud) what I had done to be picked as the Workbench customization guy. Copious amounts of alcohol on weeknights helped some, but honestly it still royally sucked. Because of these early childhood scars, I’ve cringed at the thought of this ACT thingy until now. I figured I’d been there, done that and I had zero, and I mean zero desire to relive any of it.

So, I resisted ACT even after multiple “suggestions” from upper management that I figure out something to do with it. That was wrong of me; I should have been quicker to given ACT a fair shot. ACT is a whole bunch better than the bad ol’ days of JScript. How is it better? Well, it has documentation… Also, there are multiple helpful folks back at Canonsburg and elsewhere that know a few things about it. This is opposed to the days when just one (brilliant) guy in India named Rajiv Rath had ever done anything of consequence with JScript. (Without him, my previous customization efforts would simply have put me in the mad house. Oh, and he happens to know a thing or two about ACT as well…)

## Look Ma! My First ACT Extension!

In this post we are going to rig up the PID thermostat boundary condition as a new boundary condition type in Mechanical. In ACT jargon, this is known as adding a pre-processing feature. I’m going to refer you primarily to the training material and documentation for ACT that you can obtain from the ANSYS website on their customer portal. I strongly suggest you log on to the portal and download the training material for version 15.0 now.

### Planning the Extension

When we create an ACT extension we need to lay things out on the file system in a certain manner. At a high level, there are three categories of file system data that we will use to build our extension. These types of data are:

1. Code. This will be comprised of Python scripts and in our case APDL scripts.
2. XML. XML files are primarily used for plumbing and for making the rest of the world aware of who we are and what we do.
3. Resources. These files are typically images, icons, etc… that spice things up a little bit.

Any single extension will use all three of these categories of files, and so organizing this mess becomes priority number one when building the extension. Fortunately, there is a convention that ACT imposes on us to organize the files. The following image depicts the structure graphically.

We will call our extension PIDThermostat. Therefore, everywhere ExtensionName appears in the image above, we will replace that with PIDThermostat in our file structure.

### Creating a UI for our Load

The beauty of ACT is that it allows us to easily create professional looking user experiences for custom loads and results. Let’s start by creating a user interface for our load that looks like the following:

As you can see in the above user interface, all of the controls and inputs for our little PID controller that we designed in Part 1 of this blog series are present. Before we discuss how we create these user elements, let’s start with a description of what they each mean.

The first item in the UI is named Heat Source/Sink Location. This UI element presents to the user a choice between picking a piece of geometry from the model and specifying a named selection. Internal to the PID controller, this location represents where in the model we will attach the control elements such that they supply or remove energy from this location. ACT provides us two large areas of functionality here. First, it provides a way to graphically pick a geometric item from the model. Second, it provides routines to query the underlying mesh associated with this piece of geometry so that we can reference the nodes or elements in our APDL code. Each of these pieces of functionality is substantial in its size and complexity, yet we get it for free with ACT.

The second control is named Temperature Monitor Location. It functions similarly to the heat source/sink location. It gives the user the ability to specify where on the model the control element should monitor, or sense, the temperature. So, our PID controller will add or remove energy from the heat sink/source location to try to keep the monitor location at the specified set point temperature.

The third control group is named Thermostat Control Properties. This group aggregates the various parameters that control the functionality of the thermostat. That is, the user is allowed to specify gain values, and also what type of control is implemented.

The forth control group is named Thermostat Setpoint Properties. This group allows the user to specify how the setpoint changes with time. An interesting ACT feature is implemented with this control group. Based on the selection that the user makes in the “Setpoint Type” dropdown, a different control is presented below for the thermostat setpoint temperature. When the user selects, “User Specified Setpoint” then a control that provides a tabular input is presented. In this case, the user can directly input a table of temperature vs time data that specifies how the setpoint changes with time. However, if the user specifies “Use Model Entity as Setpoint” then the user is presented a geometry picker similar to the controls above to select a location in the model that will define the setpoint temperature. When this option is selected, the PID controller will function more like a follower element. That is, it will try to cause the monitor location to “follow” another location in the model by adding or removing energy from the heat source/sink location. The offset value allows the user to specify a DC offset that they would like to apply to the setpoint value. Internally, this offset term will be incorporated into the constraint equation averaging method to add in the DC offset.

Finally, the last control group allows the user to visualize plots of computed information regarding the PID controller after the solution is finished. Normally this would be presented in the results branch of the tree; however, the results I would like to present for these elements don’t map cleanly to the results objects in ACT. (At least, I can’t map them cleanly in my mind…) More detail on the results will be presented below.

So, now that we know what the control UI does, let’s look at how to specify it in ACT

### Specifying the UI in XML

As mentioned at the beginning, ACT relies on XML to specify the UI for controls. The following XML snippet describes the entire UI.

<extension version=“1″ name=“ThermalTools”>

<guid shortid=“thermaltools”>852acb16-4731-4e91-bd00-b464be02b361</guid>

<script src=“thermaltools.py” />

<interface context=“Mechanical”>

<images>images</images>

<callbacks>

<oninit>initThermalToolsToolbar</oninit>

</callbacks>

<toolbar name=“thermtools” caption=“Thermal Tools”>

caption=“PID Thermostat Control”>

<callbacks>

</callbacks>

</entry>

</toolbar>

</interface>

<simdata context=“Mechanical”>

<callbacks>

<getcommands location=“post”>writePIDThermostatPost</getcommands>

<onremove>removePIDThermostat</onremove>

<onsuppress>suppressPIDThermostat</onsuppress>

<onunsuppress>unsuppressPIDThermostat</onunsuppress>

<oncleardata>cleardataPIDThermostat</oncleardata>

</callbacks>

<property name=“ConnectionGeo”  caption= “Heat Source/Sink Location”

control=“scoping”>

<attributes selection_filter=“vertex|edge|face” />

</property>

<property name=“MonitorGeo”  caption= “Temperature Monitor Location”

control=“scoping”>

<attributes selection_filter=“vertex|edge|face|body” />

</property>

<propertygroup name=“ControlProperties” caption=“Thermostat Control Properties”

display=“caption”>

<property name=“ControlType” caption=“Control Type”

control=“select” default=“Both Heat Source and Sink”>

<attributes options=“Heat Source,Heat Sink,Both Heat Source and Sink”/>

</property>

<property name=“ProportionalGain” caption=“Proportional Gain”

control=“float” default=“0″/>

<property name=“IntegralGain” caption=“Integral Gain”

control=“float” default=“0″/>

<property name=“DerivativeGain” caption=“Derivative Gain”

control=“float” default=“0″/>

</propertygroup>

<propertygroup name=“SetpointProperties” caption=“Thermostat Setpoint Properties”

display=“caption”>

<propertygroup name=“SetpointType” display=“property” caption=“Setpoint Type”

control=“select” default=“User Specified Setpoint”>

<attributes options=“User Specified Setpoint,Use Model Entity as Setpoint”/>

<propertytable name=“SetPointTemp” caption=“Thermostat Set Point Temperature”

display=“worksheet” visibleon=“User Specified Setpoint”

control=“applycancel” class=“Worksheet.PropertyGroupEditor.PGEditor”>

<property name=“Time” caption=“Time” unit=“Time” control=“float”></property>

<property name=“SetPoint” caption=“Set Point Temperature”

unit=“Temperature” control=“float”></property>

</propertytable>

<property name=“SetpointGeo”  caption= “Setpoint Geometry”

visibleon=“Use Model Entity as Setpoint” control=“scoping”>

<attributes selection_filter=“vertex|edge|face|body” />

</property>

</propertygroup>

<property name=“SetpointOffset” caption=“Offset” control=“float” default=“0″/>

</propertygroup>

<propertygroup name=“Results” caption=“Thermostat Results” display=“caption”>

<property name=“ViewResults” caption=“View Results?” control=“select” default=“No”>

<attributes options=“Yes,No”/>

<callbacks>

<onvalidate>onViewPIDResults</onvalidate>

</callbacks>

</property>

</propertygroup>

</simdata>

</extension>

Describing this in detail would take far longer than I have time for now, so I’m going to direct you to the ACT documentation. The gist of it is fairly simple though. XML provides a structured, hierarchical mechanism for describing the layout of the UI. Nested structures appear as child widgets of their parents. Callbacks are used within ACT to provide the hooks into the UI events so that we can respond to various user interactions. Beyond that, read the docs!! And, hey, before I hear any whining remember that in the old days of Jscript customization there wasn’t any documentation! When I was a Workbench Customization Kid we had to walk uphill, both ways, barefoot, in 8’ of snow for 35 miles… So shut it!

### Making the Magic Happen

So, the UI is snazzy and all, but the heavy lifting really happens under the hood. Ultimately, what ACT provides us, when we are creating new BCs for ANSYS, is a clever way to insert APDL commands into the ds.dat input stream. Remember that at its core all Mechanical is, is a glorified APDL generator. I’m sure the developers love me reducing their hard labor to such mundane terms, but it is what it is… So, at the end of the day, our little ACT load objects are nothing more than miniature APDL writers. You thought we were doing something cool…

So, the magic happens when we collect up all of the input data the user specifies in our snazzy UI and turn that into APDL code that implemented the PID controller. This is obviously why I started by developing the APDL code first outside of WB. The APDL code is the true magic. Collecting up the user inputs and writing them to the ds.dat file occurs inside the getcommands callback. If you look closely at the XML code, you will notice two getcommands callbacks. The first one calls a python function named: writePIDThermostatLoad. This callback is scheduled to fire when Mechanical is finished writing all of the standard loads and boundary conditions that it implements natively and is about to write the first APDL solve command. Our commands will end up in the ds.dat file right at this location. I chose this location for the following reason. Our APDL code for the PID thermostat will be generating new element types and new nodes and elements not generated by Workbench. Sometimes workbench implements certain boundary conditions using surface effect element types. So, these native loads and boundary conditions themselves may generate new elements and element types. Workbench knows about those, because it’s generating them directly; however, it has no idea what I might be up to in my PID thermostat load. So, if it were to write additional boundary conditions after my PID load, it very well might reuse some of my element type ids, and even node/element ids. The safer thing to do is to write our APDL code so that it is robust in the presence of an unknown maximum element type/real constant set/node number/etc… Then, we insert it right before the solve command, after WB has written all of its loads and boundary conditions. Thus, the likelihood of id collisions is greatly reduced or eliminated.

Note, too, that ACT provides some utility functions to generate a new element type id and increment the internal counter within Workbench; however, I have found that these functions do not account for loads and boundary conditions. Therefore, in my testing thus far, I haven’t found them safe to use.

The second getcommands callback is setup to fire when Workbench finishes writing all of the solve commands and has moved to the post processing part of the input stream. I chose to implement a graphing functionality for displaying the relevant output data from the PID elements. Thus, I needed to retrieve this data from ANSYS after the solution is complete so that I can present it to the user. I accomplished this by writing a little bit of APDL code to enter /post26 and export all of the data I wish to plot to a CSV file. By specifying this second getcommands callback, I could instruct Workbench to insert the APDL commands after the solve completed.

### Viewing the Results

Once the solution has completed, clicking on the “View Results?” dropdown and choosing “Yes” will bring up the following result viewer I implemented for the PID controller. All of the graphing functionality is provided by ACT in an import module called “chart”. This result viewer is simply implemented as a dialog with a single child control that is the ACT chart widget. This widget also allows you to layout multiple charts in a grid, as we have here. As you can see, we can display all of the relevant output data for the controls cleanly and efficiently using ACT! While this can also be accomplished in ANSYS Mechanical APDL, I think we would all agree that the results are far more pleasing visually when implemented in ACT.

## Where Do We Go from Here?

Now that I’ve written an ACT module, my next steps are to clean it up and try to make it a little more production ready. Once I’m satisfied with it, I’ll publish it on this blog and on the appropriate ANSYS library. Look for more posts along the way if I uncover additional insights or gotchas with ACT programming. I will leave you with this, however. If you have put off ACT programming you really should reconsider! Being mostly new to ACT, I was able to get this little boundary condition hooked up and functioning in less than a week’s time. Given the way the user interface turned out and the flexibility thus far of the control, I’m quite pleased with that. Without the documentation and general availability of ACT, this effort would have been far more intense. So, try out ACT! You won’t be disappointed.

Posted in The Focus | | 1 Comment

## Color 3D Printer Added to PADT’s Rapid Prototyping Product and Services Offering

PADT’s new Objet500 Connex3 is up and running, just in time for our 20th Anniversary party tonight.  The latest machine from Stratasys is the first true 3D Color Printer that allows users to print accurate and durable parts in whatever combination of color they want, including tinted transparent material. The machine is comfortably nestled between our FORTUS 400 and FORTUS 250MC.

We are especially pleased to have several executives and support people from Stratasys, the manufacturer of this machine, here for our party tonight.  They will be around to answer questions and will be offering a brief presentation on their technology as well.

Yesterday we successfully ran the standard “wrench” demo models:
And overnight we ran some more sample parts along with a printout of a 3D FEA result on a valve model:
The parts are still inside the support material, so you can’t see all the colors. Have no fear, we will be blogging about the FEA model very shortly.

PADT has been offering this machine for sale since its introduction in February and we have already sold one and have several other users about to purchase.  The advantages of having a color part without having to paint on are significant.  With our own machine we can now build benchmark parts for potential buyers and we can also offer color printing as part of our Rapid Prototyping services

We will be showing off this machine, along with everything else PADT does, at our party tonight.  But if you can’t make it and would like to learn more, just reach out to our sales team at sales@padtinc.com, our prototyping services team at rp@padtinc.com or just give us a call at 480.813.4884.

UPDATE:

Here is the cleaned valve displacement 3D Plot:

## Ready for a Tech Party? We Are! PADT’s 20th Anniversary Party is Tomorrow Night

Everyone here at PADT is working hard on their day-to-day tasks and getting ready for the 20th Anniversary Party tomorrow night from 5:30-9:00. The refreshments have been procured, ice is on order, and an appointment has been set to go get the cake. In light of tomorrows high temps, we even ordered two coolers to keep everyone comfortable, so “it’s too hot” is no longer a valid excuse.

Tomorrow around noon, all of PADT’s employees will gather together for a special anniversary pictures, attend a company meeting, then set everything up.

All we need now is you!

Even though we have been suffering from construction delays, the new demo & server room is finished enough to show everyone around.  In the new room, will be highlighting our CUBE HPC hardware and the new Objet 3D Color Printer in this new facility, along with the scanners and other Additive Manufacturing machines you have all come to know and count on:

Here are some reminders for those that can make it:
• Everyone is invited, no need to RSVP. Just come and bring a friend.
• If you are social network kind of person, please tag any posts: #padt20
• We will have plenty of food and drink
• Entertainment will be provided for the young (and young at heart) with a bouncy-house and a magician
• We will be featuring music from 1994… but it is an engineering event so don’t expect a lot of dancing.
• Come at any time you want. Speeches and door price drawings will be from 6:30-7:00
• We will be handing out some swag, first come first serve for t-shirts and slap bracelets.

For those of you who could not make it, a big thank you for all the fantastic best wishes and congratulations.  We really appreciate all the support everyone has given us over the past 20 years.