How does Pollination create room names when exporting to gbXML?
The gbxml export results in room names that don’t match room naming in the Pollination file.
How does Pollination create room names when exporting to gbXML?
The gbxml export results in room names that don’t match room naming in the Pollination file.
Hi @heathbaxa, can you be more specific about the issue here?
@chriswmackey can add more details here but we use a specific tag to include the display name
in gbXML called Name
. Not every tool imports that tag. If that’s the case, you must change the identifiers based on the display names using the Python Script Editor. I can provide you with an example if that is the case.
From the Pollination Editor, I select export to GBXML format. Full Geometry.
Importing the file to Trace700. I’m testing this to speed up inputs for my HVAC engineer colleagues who are still using Trace 700 for load calculations.
Nice! That’s helpful.
For TRACE700 workflow you should use the TRACEXML export option instead of the default gbXML. It creates a gbXML file that is compatible with the TRACE gbXML importer. There are also other simplification options that you should probably leave as is for your export to simplify the windows.
It should also fix the naming issue. Let us know otherwise!
We have been working with the TRACE TRANE team to develop the modified gbXML but we haven’t announced it officially yet. Let us know if you face any issues and we will be happy to help.
Thanks, @heathbaxa
You are right that exporting the TRACE gbXML will address the issue, @mostapha . In the default gbXML export, we write the room’s display_name to the <Name>
tag in the gbXML and we let the Space id be governed by the original Revit object id:
But we learned that TRACE 700 (and TRACE 3D) just ignore this (pretty useful) <Name>
tag and instead name all of the rooms with the id. ¯\_(ツ)_/¯
When you export a TRACE gbXML from the model editor, we overwrite all of the IDs of the objects using a cleaned version of the names. So, instead, it looks like this:
Which will look better when importing to TRACE.
Thanks! I have tried several of my projects. While I can export to several formats (GEM, INP, GBXML) without error, I get errors on all of them when I select TRACEXML.
Thanks, @heathbaxa .
This sounds like a bug. What is the error that you are getting when you select TRACEXML? If you can get us the error message and/or a sample file to recreate the error on our end, we will fix it.
@heathbaxa, after thinking about this a little bit more, is it possible that you are using an older version of the Revit plugin/Model Editor that doesn’t have the latest SDK? Do you see this warning when you open the Model Editor?
Support for SDDXML was added in version 1.16.
I have the latest Model Editor. I was able to work through the issue and get a proper TRACEXML output on a couple of the test models. Prior to export I verified that the model was valid. I tried several things, but if I recall correctly after I solved adjacency, then the export to TRACEXML worked. I will let you know if I have issues again.
Thanks! Then I consider this topic as resolved for now. Let us know the feedback on TRACEXML quality.
One item that we have been thinking about is building some sort of report for people to be able to validate the imported model against how they would have put the numbers into TRACE manually. Let us know if your mechanical engineer thinks that can be helpful, and if yes, how would the report look like.
Thanks!
Ah, yea, I guess we haven’t really made a video about “how to format your Pollination Models for TRACE” but TRACE expects you to have a model with solved adjacencies just like EnergyPlus and DOE-2. It doesn’t have some internal mechanism to figure out adjacencies for you the way that IES-VE and IDA-ICE do.