I've been using SMath for several years, but have always had to use it set to Metric for default units even though I work in the US with Imperial units. It's never worked as expected with Imperial units, so for every worksheet I write, I manually convert every single entry from meters to inches, megapascals to ksi, etc. I tried setting it to Imperial units as a default again to see if it worked any better now. But as you can see below, it still has some issues. The formula below works fine when set to metric, but not, ironically, to Imperial. I've had similar issues in the past every time I tried using Imperial. Are there any workarounds or ways to fix this going forward? I normally just deal with the manual line by line conversion, but the "Ceil" function that I want to use on the resulting decimal column size didn't work even with it set to metric (it just rounded 26.453 inches up to 1m, or 39.37 inches, instead of the correct 27 inches), so my typical approach of using Metric doesn't work here either. Any ideas (or a fix) to make Imperial units work correctly would be much appreciated.

Some people have modified the units.xml file located in the entries folder of the install files so that the default units are US. If you know enough of what to do you can modify the units to work how you want, but make sure you know what you're doing.

Related Post: Custom units.xml

If you search for units.xml you will find some other posts.

Also, you will need to make a copy of this units.xml file because when you install an update, it will be overwritten.

Wrote

Also, you will need to make a copy of this units.xml file because when you install an update, it will be overwritten.

OK, thanks. That's good to know. I use SMath almost every day, but other engineers in my office only use it once in a while, so this does introduce some additional overhead in terms of program management. It would be nice if this functionality could be rolled into the main program.

Yeah, I know what you mean. Changing the units setting in the settings file doesn't really work because you can't select your default units. You still end up manually changing all the outputs anyways.

What I found easy was to keep a copy with the extension .bak in the same folder and then when I update, I manually go in and copy it and rename to replace. You might be able to make an independent vbscript or .bat file to replace the units.xml file automatically. I'm not sure what is possible, but you might even be able to make a script file that detects when the units file is changed, and changes it automatically. Just an idea.

The best part about working with the units file is that you can set default unit outputs. So if you work mainly in kips, this is nice, or lbf, whatever you need.

Wrote

The best part about working with the units file is that you can set default unit outputs. So if you work mainly in kips, this is nice, or lbf, whatever you need.

Hmmm. That could be useful. I wasn't even aware of this units.xml file until yesterday, so I'll have to look through it closer and understand it better. Can you define new units in there as well, so that they are recognized like the typical units? We use units of force per unit length a lot in structural design (e.g. kips/foot, typically denoted klf, for kips per linear foot). There isn't any force/length unit currently defined, so I usually just define a plf:lbf/ft and klf:kip/ft at the beginning of each worksheet, and similarly for ksf:kip/ft^2. But if I could define those in the xml file and have them recognized in new worksheets, that would be a nice improvement.

Yes, I believe you can define your own “new” units.
If you search on the forum regarding the units.xml file, there are some posts about custom units using the xml file.

Well, one problem has come up. Switching to the US Units.xml file works pretty well if I'm starting a worksheet with that, but not if I'm opening a prior worksheet that was done with the Metric basis, even if the units were all US units in it. Errors come up everywhere for inconsistent units. I have dozens (maybe 150 or so) SMath worksheets that would be troublesome to go through converting... And I found that SMath (or Windows?) doesn't like me keeping an "extra" file in that system folder, and then I have to confirm I have administrator rights 3 times each time I replace the metric file with the US file. Sure would be nice if the units management could be handled in the program rather than through editing of files in Windows system directories, that seem to be, at best, a workaround.

Jason

Here's a question. Can SMath be installed in 2 separate installs on the same computer? I was thinking that that might be a way to work around this issue with the different xml files for units: have a "standard" install in the default directory with the default Units.xml file in place, and a "US" install in a parallel directory that could have the US version of Units.xml in place. Then I could just label one shortcut "SMath (US)" and use it when I wanted to use the US Units.xml file without having to swap files manually before using the program each time. However, it doesn't seem to allow that when I just tried. Any thoughts?

Jason

My short answer is NO, Win can't be split in parallel machines
Win in a serial vector machine. I wish be wrong.
There would be long times exploited so !
Jean

Wrote

Here's a question. Can SMath be installed in 2 separate installs on the same computer? I was thinking that that might be a way to work around this issue with the different xml files for units: have a "standard" install in the default directory with the default Units.xml file in place, and a "US" install in a parallel directory that could have the US version of Units.xml in place. Then I could just label one shortcut "SMath (US)" and use it when I wanted to use the US Units.xml file without having to swap files manually before using the program each time. However, it doesn't seem to allow that when I just tried. Any thoughts?

Jason

There is a portable version for SMath which Martin (mkraska) provides.
A couple years ago while I was using windows, creating a file "portable.version" would made that folder of SMath portable too.
You could make portable extensions, plugins, config files, visa versa under that folder. I don't know if this still works.

Regards

Installing two instances of SM doesn't work out to well. Having a portable version and a fixed install does.

You can make any version of SM portable by adding blank text file to the same folder as the exe, then change the text file to system file with name "portable" and extension "version" (portable.version)

Here is a snip of a fixed install running side by side with a portable install. The portable install will only reference the files and setting in the root folder of the install. So in Theory, the portable version could be the US units version and the fixed, the default metric.

Wrote

You can make any version of SM portable by adding blank text file to the same folder as the exe, then change the text file to system file with name "portable" and extension "version" (portable.version)

Here is a snip of a fixed install running side by side with a portable install. The portable install will only reference the files and setting in the root folder of the install. So in Theory, the portable version could be the US units version and the fixed, the default metric.

That's cool. I've heard the term "portable" thrown around on these forums before, but didn't know what that signified. Adding the portable.version file worked, but then I get the following error when trying to install a plugin. Any ideas on how to proceed? Deleting the portable.version file allows the program to work as expected with all plugins recognized.


Although I can copy the currently installed version to an "SMath Studio (US) directory and add the portable.version file to that directory and confirm one is standard and the other portable, it may not help if I can't get the plugins that are used in the worksheet to be recognized on the portable version. Something to do with Windows permissions, maybe?

I would try to install all the extensions I need first and then “convert” the install to a portable version.

Wrote

I would try to install all the extensions I need first and then “convert” the install to a portable version.

Well, that's the thing. If I delete the portable.version file out of that 2nd install directory, then everything works and there are no plugins to install. They're already loaded, and in fact, I'm already signed in. I'm directly opening the exe file in the 2nd install directory, but I would almost think it was using the program exe from the standard install the way everything comes up, except for the fact that it opens the worksheet built on the US units.xml file correctly, so I know it's in that 2nd install directory. Is there another place that the plugins are tracked or stored? Because both install directories have identical plugins folders, and neither is anywhere near all of the plugins I've installed.

Some seem to be in the extensions folder and other in the plugins folder.

Wrote

Some seem to be in the extensions folder and other in the plugins folder.

Extensions folder? I don't have that on either install... Is that in your Program Files (x86) directory? I don't see any other directories under Program Data or elsewhere that it could be, but then stuff seems to get hidden everywhere these days.

Okay, I just did a simple test. I copied my current install folder containing my smath installation with all the extensions/plugins in place. I converted the copy to a portable version. I then changed the units.xml file in the portable version. Then I opened each version by clicking on each versions exe file. Both seem to work just fine and contain the same extensions.

Clicking directly on .sm files will prompt the regular installation, so to open with the portable version, you need t first open the portable version through its exe, then open the file you want to work on through the open file in the tool bar.

There is no need to install again, just simply copy the current install. I have it installed on a second SSD that is not the C drive, but if you have it on the C drive, I think having it in C:\Users\"your username"\AppData\Local\Programs seems like a good place.

Wrote

Wrote

Some seem to be in the extensions folder and other in the plugins folder.

Extensions folder? I don't have that on either install... Is that in your Program Files (x86) directory? I don't see any other directories under Program Data or elsewhere that it could be, but then stuff seems to get hidden everywhere these days.

hmmm, it may be that my install folders are a bit mixed up as I was messing around with trying to find the applications folder. I would start by getting my installation how I want it with all the extensions etc. Then copy the entire install folder as I described before and converting it to portable and then make your portable version the one with the custom units.xml file.

Yes, I had already copied over the install folder rather than trying to install a 2nd copy like I had been before, but it still wasn't working. But it must've been something to do with having the copied installation still in the Windows Program Files (X86) directory. I moved it over to the User AppData directory as you suggested, and it works like a champ now! In fact, I can have 2 worksheets open simultaneously in 2 separate instances, one using the default units.xml file and the other using the US units.xml file, even if I don't have the portable.version file in the 2nd install directory. Thank you for all your help!

Jason