I am working on a test model to evaluate the implementation of Pollination in a workflow for creating gbXML models
I am encountering some issues regarding the interpretation of certain surfaces:
Certain internal floor surfaces are interpreted as roof. The rhino geometries are adjencent and the PO_solveadjency works for all the surfaces except these few ones.
1.2. When I try to change the surface boundary condition from Roof to surface I get this message “a valid surface boundary condition must be a list that consists of 2 or 3 identifiers” but I don’t find a way or command to change the surface condition after that.
Floor and ceilings gets exported in gbXML in a non uniform way: some floors are interpreted as ceilings.
I’ll have a look and will record a video for you. May I ask why do you need to use a gbXML? Where are you trying to export the model? We recommend using the GEM file format for IES VE and only using the gbXML if we don’t have native support for your target software.
Well… it’s not my choice to use gbXML…
The software we are trying to use for the energy analysis is Lesosai and the only format that it accept as import is gbXML (and IFC…)
So that’s why we are stuck on using this format…
I am not sure if most of these issues are due to a wrong use of the Pollination plug in or if there is some bug in the gbXML export…
Hi @piusto, I had a closer look, and my conclusion is that the issue happens in the translation from OSM to gbXML. I documented the issue with @chriswmackey who knows more than I do about this, and he will get back to you about this.
Here is more information:
We use the OpenStudio SDK for translating the model to gbXML. That means we create an OpenStudio model (OSM) first, and then use OpenStudio functionalities to create the gbXML file.
To see if the issue happens before creating the gbXML, I cleaned up your model, fixed all the validation issues, and exported it to an OSM file. The normal directions looked correct.
I found this older issue on GitHub that shows other people have faced a similar issue in the past.
Let’s see what @chriswmackey has to say about this. I’m not sure if we can do much but we might be able to provide a script to fix these issues in a gbXML file after the file is created to solve the issue for you. I also know that there has been a new release of the OpenStudio SDK that might have addressed this issue.
Any chance that Lesosai has a native file format that we can create directly? You’re the 3rd user who is asking for exporting to Lesosai software. I don’t know anyone from their team to get in touch with.
I know it might be hard to believe but in most cases, it has been easier to add and maintain a new exporter to other tools that create the native input file format for those platforms instead of trying to fix the gbXML routine. ¯\_(ツ)_/¯
What you are seeing is not a bug but rather just the nature of the gbXML file schema. gbXML is a non-manifold geometry schema, which means that there is only one of the two adjacent internal Faces included for each interior face pair in the model. I guess this non-manifold structure served some of the goals of the original gbXML authors but it makes it practically impossible to treat Rooms as self-contained units, making it very hard to edit gbXML files on a room-by-room basis. This is one of the many reasons why OpenStudio team (and we) have decided not to use non-manifold geometry in our own schemas, even though it’s technically what engines like EnergyPlus are using under the hood. Instead, each Room is a closed volume, which results in two adjacent face pairs for each interior Face of the model.
Whichever of the two interior Faces that actually makes it from the Pollination Model/HBJSON/OSM into the gbXML file is essentially a selection based on whichever one the OpenStudio translator finds first. This is why it seems kinda random that there are some interior floors and some interior ceilings.
But, long story short, we are exporting the gbXML correctly and interfaces like DesignBuilder should not have an issue importing the gbXMl that you have saved. I don’t have experience with Lesosai but, if their gbXML importer is as good ad DesignBuilder, it also should not have any issues.
Spider is just going to show you the true nature of the gbXML, which may be a little ugly sometimes but that is not your fault.
FYI, that old OpenStudio issue is about the gbXML importer built into OpenStudio. NOT the gbXML exporter that we are using here.
Granted that GitHub issue was fixed a long time ago but you can imagine that it would be easy to create bugs about normal direction when trying to convert from gbXML’s non-manifold schema back to a schema of complete Room volumes like what OpenStudio uses.
Also, you know that I will always agree with this:
Not that the gbXML route is impossible but we know OpenStudio isn’t the only BEM platform that has struggled to translate back and forth between the non-manifold schema.
Thank you, @chriswmackey for the clarification. @piusto, does Lesosai gives you an error when you import the gbXML file that is created by Pollination? Based on Chris’s comments what you see in Spider is the expected output.
Here is a gbXML file that I exported from Pollination after cleaning up your model.
fist of all thanks for the feedback, it’s great to see such a dedicated team like yours!
Regarding the issue #2
I see the problem with the gbXML export/schema limitations… although does this happen with all the models exported with Pollination?
we are testing it because we want to move away from creating gbXML with Revit. We had many issues with exporting gbXML with Revit although the floor/ceiling interpretation was always correct. So there might be something under the hood that the Revit converter is doing better then OpenStudio/Pollination?
(at least for that part… we know about the other atrocities that Revit does when exporting to gbXML )
Anyway this is not a major issue as we might be able to fix it afterward in Lesosai…
Regarding issue #1
This does not seem as a gbXML issue as the incorrect surface interpretation is evident in pollination already. And there seems to be no manual workaround to change the surface type afterward… is this correct?
Regarding Lesosai:
Yes we can definitely get you in touch with their development team.
I don’t know about how much we can interact with Lesosai native file but I will also have a look into that…
Regarding why we are using it: Lesosai is the only certified software in Switzerland that has been tested for different local regulations regarding the evaluation of gray energy and natural lighting.
I’m not sure if my explanation was clear but the gbXMLs that Pollination and OpenStudio export are correct according to the gbXML committee and its validation routines.
But it sounds like you (and I guess Lesosai?) have some other criteria in addition to this base validation for what you expect a “correct” gbXML to be. This kinda illustrates the problem with gbXML that everyone came up with their own definition of what they thought was “correct” and, by the time that the gbXML committee started writing validators to establish what is objectively considered correct, it was too late.
But maybe we can add an option for some other rule that you (or Lesosai?) have if talking do the Lesosai developers doesn’t provide us with a better route. You’d just have to let us know what you are expecting here. Should all interior horizontal faces be floors? Or should they all be ceilings? I guess we have established that having some floors and others ceilings is not what you want.
Can you share a simple sample file with us that is exported from Revit. There might be a workaround that we are not aware of.
Hmm. I will double check, but I believe the boundary conditions are exported correctly.
That would be great!
Is it possible for you to save your project from Lesosai? In that case, how does the file look like? If it is an ASCII file, we should be able to figure it out.
Understood! We had a couple of other users bringing up the software. We’re keen to provide a reliable integration with Lesosai.
This one for instance was exported from Revit, it has many other issues but at least the floor / ceilings are defined correctly: FP5_NO HVAC Zone_OK.xml (954.1 KB)
Will provide you one very soon…
It might be a smaller user base… but if it could work then a lot of modelers would use Pollination in Switzerland…!
As I mentioned we should distinguish issue #1 from issue #2 (I should have made two posts…)
Issue #1 is still unresolved, @mostapha is looking into it, this one has a major impact on the export of gbXML as it results in having roof surfaces inside the building (where they obviously should not be). This issue is already evident in the pollination interface before exporting.
Issue #2 regard the misplaced floor / ceiling surfaces, we understood this issue is generated by the “nature” of the gbXML schema. This is not as important as issue #1 as the surface type can be fixed afterward in Lesosai… Of course what a “correct” schema could have multiple interpretation but I think we all agree we should have uniformity across floor surfaces of a multi story building?
From your file, I can see that your interpretation of “correct floor / ceilings” just means that you never use the gbXML interior “Ceiling” type and you represent all interior horizontal surfaces with the gbXML “InteriorFloor” type. I did a little cleanup on your gbXML model with the Rhino plugin and, using the gbXML exported from Pollination, I just did a find and replace to change “Ceiling” to “InteriorFloor” in the gbXML. Here is the result:
If you confirm that this is what you were looking for, then it should be easy for us to add an option into our gbXML export routine that just replaces all of the interior “Ceilings” with “InteriorFloor” so that you can get exactly what you want without having to do a find and replace.
Hi @piusto, @chriswmackey already answered the other question, and we can add an option to make the selection of ceiling vs interior floors consistent.
For the flipped face, it was happening because your model was invalid. Here is the fixed model and the exported gbXML.
There were also some invalid interior doors which I didn’t fix.
One last question, if you have these models inside Revit why don’t you use the Pollination Revit plugin to export them to gbXML? You don’t have to go through Rhino.
@mostapha
Wow, thank you so much for the fix and the explaining video…! I guess I was not really fixing the validation issues and also I was not aware of commands like PO_OffsetChildObjects. I will definitely study the manual a bit more, but the video is great and show clearly how to fix the issues.
Regarding this: as I mentioned we are trying to move away from the modeling with Revit as we want to create a new workflow for a class @Usi
Our students will create some energy models starting from scratch from many different buildings. So the workflow we are defining will be replicated by them on their specific project. We figured the Rhino approach would have been the easiest one as we model the gbXML geometries directly (and not indirectly as it happens in Revit).
So it’s important for us also to understand how to fix these model issues as I am sure there will be some in their exercises…
In the meantime thank you very much for your help, I think it’s clear we can integrate Pollination in our course workflow now!
I’m glad to hear that. @chriswmackey has already implemented this option in the core library, we will expose it in the Rhino plugin soon.
No problem! I would suggest watching this workshop for now, until we update all the other videos. It covers most of the commands for fixing the models.
I missed the context here. If you have the option to use Rhino directly, then I strongly recommend using Rhino over Revit for your class.
My pleasure! It would be great if you could still put us in touch with the developers of Lesosai to explore a direct integration. Hopefully, the gbXML workflow will be good enough for your studio but having a direct export will be more reliable in the future.
Welcome to the forum.
)
