Idea: delete all duplicate adjacents

[EK-CEL]

Revit generates gbXML file (see the attachment) having many duplicated surfaces:

I think it is kind of Revit bug and I would like to get rid of those surfaces. It would be nice to have a 'delete all' button under the 'Issues > Duplicate Adjacents' toggle. Hope it doesn't harm the model.

Revit gbXML model: 17134-M17.zip

[theo-armour]

@EK-CEL

Good point. If 'Aragog' can spot an issue then we want it to also be able to fix the issue.

This is beginning to happen in R13

Clicking the fix button brings a dialog that looks like this

All of this is still at an early stage. Duplicate adjacent spaces is going to be a tricky one to fix because in many cases we need to help you find which of all the spaces is the best one to suggest.

Hope it doesn't harm the model.

The model always to be protected is the Revit model. The purpose of Aragog is to get data into your analysis program and help you get more accurate results faster.

I think it's OK to accept that Aragog may goof up from time to time - because the original Revit model is never never touched.

Update

Thanks for the model. Looks interesting and complex. Can you see if Spider could use this as a sample model - properly credited of course?

[EK-CEL]

@theo-armour Thank you for the response. It is nice to see that Aragog is moving forward, and implementing user's wishes.  

harm the model.

I meant that elements is gbXML are interconnected, and changing an element we should consider its relations to others. For example we cannot simply remove a material because many surfaces may refer to that material. Breaking required relationship between elements can prevent the "fixed" gbXML model to be imported into energy calculation software. I don't know the gbXML file format well enough to say that we can delete the adjacent surface without affecting other elements. So I just "hope" :-).

[EK-CEL]

The attached gbXML file is generated from the real Revit project for the building which is under construction. It means, that the model is as good as we can have from architects. Sure it is not perfect. We can make some adjustments to eliminate obvious issues like missing roof and exterior walls. Some issues which we cannot fix with Revit can be fixed with Spider (thank you the team!). But it is only part of the problem. A Revit generated gbXML model can have hundreds of issues. I think it is impossible to fix them with Revit. Personally, I don't care about all those duplicated space surfaces and coordinates, vertexes, tiny surfaces, etc. I would ignore them just to get to my calculations as fast as I can. But, unfortunately a load calculation software (like IES VE) is too picky and doesn't allow a model which has some issues. It is frustrating: I take a gbXML model from one software (Revit), bring it to another software (IES VE) and it doesn't work. IES company doesn't have any plans to "forgive" gbXML issues. Probably we should wait till Autodesk will find a way to generate a proper gbXML model. But before that (if it ever happen) the Spider application is the software which we extremely need. It should be able to identify errors, and (I am praying for that) to fix all the problems. Thanks the Spider developing team for working for that bright future.

[theo-armour]

@EK-CEL

I don't know the gbXML file format well enough to say that we can delete the adjacent surface without affecting other elements. So I just "hope" :-).

My fingers are crossed too. I'm new to gbXML and XML as well. We will learn about this. And the best way to learn what works is to make as many mistakes as fast as possible

So our goal must to get the time spent in Aragog down to pushing a button or two. The best workflow is that you spend your time designing and analyzing. Spending time fixing wastes your time and your brain. The faster we get the Aragog worklow going, the better things are for the built environment.

It is frustrating: I take a gbXML model from one software (Revit), bring it to another software (IES VE) and it doesn't work.

I hear you.

I worked at Autodesk for a long time. The issue is they have lots of coders but few designers and engineers familiar with AEC. They have no access to workflow let alone to actual models. The analysys app makers are in the same position.

The solution must come directly from the community of users - people with access to models and who live and breathe the workflow from design to analysis and back.

What the effort of the last six months is showing us is that many of the problems you describe are fixable. And the apps you see here now are just scratching the surface of what we will be able to do in the coming months.

I look forward to you continuing to share wore excellent workflow feedback. Thanks!

Theo

[mdengusiak]

@EK-CEL @theo-armour

We can not just delete duplicate adjacency - we need to fix them, This will destroy gbXML model.

Most of our files and all my files are generated form REAL Revit projects. Your issue with duplicated adj spaces are common Revit Issues mostly due to poor model but sometimes also due to Revit gbXML export. We using TAS and IES. Currently TAS is much more similar to Revit structure, IES is more like Rhino so we can achieve better results there with TAS. However we tested it with TAS, E+, IES, Openstudio and could run simulation in all tools.

Our Viewer is allowing you to fix them. Just select surface with duplicate Adjacency and change second space to correct one. This will allow you to fix most of your issue.

The only problem is which we can not fix right now is if surfaces are not correctly splitted. This why we need to be able to edit vertices in future to allow final model fix. However this is rate warning and right now we can fix 97% issues that come from revit.

[theo-armour]

@mdengusiak

We can not just delete duplicate adjacency - we need to fix them,

Agreed

There are going to be several cases where this is tricky

• Shade surface types with and adjacent space id
• Surface types with two adjacent spaces that should only have one
• Surfaces types like Air that require two adjacent space ids, but there no actual space there

The bigger point is that work has started in building a panel that fixes this issue. See R13.15. I will start a new issue tomorrow dedicated to a UI for handling these cases,

[theo-armour]

progress here is ongoing