Failed to load osm

Hi, I was trying to run a couple of my energy models made on the SketchUp plugin. I wanted to try the new plugin for Rhino, with the ctr-o command to open the osm file from my library. It looks like the oms file is not supported. Am I doing something wrong?

Hi @sobradopablo,

I suspect this is a problem with file path - do you have white-spaces in file path? In that case, can you try to rename the file and try again. This is a bug on our side which I thought we already fixed.

If that’s not the case then can you share the osm file with us? If you can’t share it in public send it in a private message. Thanks!

cc: @antonellodinunzio

Hi! I tried to import the osm files with no white spaces on the file name. It didn’t work. I’m sharing my osm and weather files. Please let me know if you can run them.

pollination test for (282.0 KB)
pollination test for (299.8 KB)

1 Like

Hi @sobradopablo, I can import the duplex one with no issues. The other ones gives me an error too.

Let’s wait for @antonellodinunzio to have a look!

Actually there is one more issue after importing the osm file. When I click on the rooms to edit their properties I get the null value error.

cc: @mingbo

This looks like a bug for me to investigate in the core importers. I’m assigning it to myself and I’ll take a deep look as soon as I get the chance.

So the issue is that you used an illegal EnergyPlus character in your OSM file:

So you wouldn’t be able to simulate this OSM in EnergyPlus. Once you replace the “ñ” with the ASCII “n”, it all works correctly.

Here’s an OSM that translates correctly: (59.0 KB)

I think we can probably have some better error reporting for this case but I don’t think that there’s anything that we can really do to fix it when the OSM isn’t legal in the first place.

Hi, the last plugin update did work! Thanks.
Chris, osm whit ñ did work on my openstudio app, ñ has never been an issue for me, but is good to know that I can use it for the next projects!
Thanks for your help!

I agree with @sobradopablo in this case that this is a valid osm. If I remember correctly OpenStudio uses the handles and not the name when translates the objects to EnergyPlus. As a result the ñ never makes it to EP simulation and everything will work fine. Technically we should also be able to handle it as we use identifier for translation. If I understand correctly our main limitation here has been encoding/decoding the string when write/read to/from JSON files.

OpenStudio only uses the handles internally and they never make it to the IDF.

However, I tried simulating the OSM and I see that OpenStudio replaces the non-ASCII characters with some type of ASCII representation:

… and this allows it to simulate. I don’t know what this encoding is but I guess we could do the same when we import from OpenStudio to HBJSON. Is replacing this character with some type of encoding preferred to just removing the non-ASCII character altogether?

Once you let me know the preference, I can try implementing it.

I don’t think that we need to do that. If I remember correctly we use identifiers and not the display name to write to the analysis engines. If that is still the case then we can just keep the non-ascii characters in the HBJSON file. There is an ensure_ascii=False key that we should be able to use when dumping the information. And for loading there should not be an issue. I did a quick test and it worked.

import json

data = {'Name': 'Baño A'}

data_out = json.dumps(data, ensure_ascii=False)
data_in = json.loads(data_out)

It prints out:

{"Name": "Baño A"}
{'Name': 'Baño A'}

I need the equivalent for Ruby. I’ve been searching for it over the last hour with no dice. Man, I really wish OpenStudio Python bindings were fully featured.

Ok, I implemented a fix:

I couldn’t find how to do exactly what you had suggested in Ruby but this will ensure that everything still works when there are non-ASCII characters in the OSM.

1 Like