Error on "Full Volume" and gbXML export

Hi,
i’m testdriving a little the PlugIn (2.125.2.0) like in the ACE22 Masterclass shown by Mostapha.
When the geometry calculation is set to “Full Volume”, the preview in Step 5 doesn’t show up and an error is thrown (also window ratio seems to be wrong):

Another issue is the gbXML export. While bhjosn-export works, gbXML gives an error:
grafik
Where is the logfile?

Best regards,
Heiko

Hi @heikow - Welcome to the forum! :wave:

Can you screen capture the settings in the level step? Are you setting both levels to Full Volume? I will try to recreate this issue on our end. This might be a bug related to the new changes for selecting the methods per level.

You should be able to find the path by clicking on the About button.

@heikow - I ran a quick test on my end, and I can’t recreate the issue. I will need your sample model to be able to see what’s going on in case you were not able to figure it out on your own from the logs.

Hi @mostapha, i’m working with the Basic Sample Project from Revit 2023.
First Preview works for these settings, but with fully glazed walls in level2:

After some iteration between 5-Preview and back to 3 and switching Level 2 from “Full Volume” to “Extruded Floor” i get no Preview

*2023-03-07 10:28:35.8969|FATAL|pollination_logger|System.Reflection.TargetInvocationException: Ein Aufrufziel hat einen Ausnahmefehler verursacht. ---> System.AccessViolationException: Es wurde versucht, im geschützten Speicher zu lesen oder zu schreiben. Dies ist häufig ein Hinweis darauf, dass anderer Speicher beschädigt ist.
*2023-03-07 10:38:34.0616|DEBUG|pollination_logger|& "C:\Program Files\pollination_revit\python\Scripts\dragonfly.exe" translate model-to-honeybee "C:\Users\hw\AppData\Local\Temp\0d5cc09a-a00b-44ed-a741-31266caf6a0c\tmp421B.tmp" --folder "C:\Users\hw\AppData\Local\Temp\0d5cc09a-a00b-44ed-a741-31266caf6a0c\yexw5obm.oai" --bypass-adj-check|*
*2023-03-07 10:38:37.9395|DEBUG|pollination_logger|dragonfly.cli.translate - ERROR - Model translation failed.*
*Building "Building 1[Building_dd708aad-4f14-4e88-b5e1-80b35e501ded]" is invalid:*
*Building must have at least one Story.*
[Debug.log|attachment](upload://t4RINVfkYCmSrvSfJWqjLn36vR4.log) (65.3 KB)

Here are my Versions
grafik

Hi @heikow,

Thank you for the screenshot. I was able to recreate the bug. This is happening because you are not selecting any of the rooms from level 1 in step 4. If you select the rooms it will work fine.

@ksobon, here is the process to recreate the bug.

  1. Select both rooms in step 3.

  2. Only select the rooms from level 2 in step 4.

  3. Try to visualize the rooms in step 5.

It looks like that we are still trying to create level 1 even though no rooms from level 1 has been selected. We should add a check to only create the level if at least one room is selected.

See my comment.

Hi Mostapha,
hi Konrad,

i do have to two issues:

  • Glass ratio seems not correct for “Full Volume”
  • gbXML export doesn’t work for me

Heres a screenshot with the glass ratios:

and here’s the log when i try to export to gbxml:
Debug.log (9.6 KB)

File “c:\progra~1\pollin~1\python\lib\site-packages\honeybee_energy\run.py”, line 959, in _parse_os_cli_failure
log_osw = OSW(os.path.join(directory, ‘out.osw’))
File “c:\progra~1\pollin~1\python\lib\site-packages\honeybee_energy\result\osw.py”, line 26, in init
assert os.path.isfile(file_path), ‘No file was found at {}’.format(file_path)

Hi @heikow - can you share a screenshot of the step in that you select the apertures? You might have selected a wall type as n aperture. Even the interior walls are parsed as apertures.

@chriswmackey, can you tell based on the error message why the osw file might fail to be created?

oh sorry, my fault! Seems like i missunderstood dialog 2…

1 Like

Hey @mostapha ,

If the OSW was not created, then this means that there was something really wrong that OpenStudio CLI did not like such that it did not even start translating the HBJSON to an OpenStudio format.

I see in the log that there are some characters in the file paths that I’m not sure if they are UTF-8:

OpenStudio CLI is designed to handle inputs in UTF-8, which is better than EnergyPlus’s strict enforcement of ASCII characters. But it’s not an all-inclusive character set. Maybe this could explain it?

In any event, I would think that the error is something like that and, if we had the HBJSON or DFJSON that was output from Revit, we can probably translate it to gbxml on our machines.

Thank you, @chriswmackey!

This also means that if @heikow chooses a different folder with no special characters he should be able to export the model.

In addition, we should probably use a temp folder in these scenarios and then copy the file(s) back to avoid this issue.

I should say that I thought this is how I designed the model-to-gbxml command to work but it’s possible that it’s not working as I intended it. We’ll know for sure if @heikow could share the exported HBJSON and/or if he could try exporting to a different folder and see if that works.

Thanks, german umlaute were the problem. Should have known that from radiance… thanks to both of you for the quick support!

1 Like

Thanks, @heikow ,

I think I have a good solution in mind that will address this case.

I can see that I was wrong in thinking that I had implemented the whole translation to run in a temp folder like @mostapha suggested. I currently try to have the OpenStudio CLI output the gbXML directly to the specified --output-path by writing it into the OSW:

There are some performance savings associated with this in that I don’t have to re-copy the file so I would like to keep it this way. I think I should be able to do this since the german umlaute can be encoded in UTF-8.

I think the key thing I am missing is that I don’t encode the JSON string in UTF-8 before I write it into the OSW. I can see that I do this whenever I translate the Honeybee Model to OSM:

… but I forgot to do the same when I translate to gbXML. Let me see if this fixes it on my end and I’ll let you know.

Hey @heikow ,

I have put together a fix here:

… and I verified that it allowed me to write the gbXML to file paths with umlautes in them.

Assuming our CI works correctly, you can get the fix on your end with the LB Versioner in an hour or so and the fix should be in the next release of the pollination installers.

1 Like