Running Tally in Central or Detached Model?

Hello All. I was curious if anyone could provide any insight on their experience with saving the results of Tally after a study is complete.

The first part of the question is related to the difference in running Tally in a local copy of a central Revit model vs. running Tally in a detached model. It seems that the ideal would be to perform the analysis in the Central model, because the material mapping would not have to start from scratch if you did a second LCA study later in design after more changes had been made to the model. However, after watching some tutorials, the recommendation of some was to run Tally in a detached model to avoid compromising the central model. Can anyone confirm that they have experienced issues when running Tally in the central model?

A sort of follow up question to this is, can anyone provide insight on methods to keep the material mapping history stored in a central model? The goal here would be to make it such that anyone who opens a local copy of a central model that has previously had an Tally study done on it does not have to redo the material mapping process, and keeps the material mapping consistent with previous studies. In the few studies I have done so far, sometimes this works, and sometimes it does not, and I cannot figure out why.

Thanks!

1 Like

Hi John,
I’m a proponent of detaching though I understand your point about design continuity. If running analyses throughout the design process is the admirable plan then I would agree – staying in the main model would be ideal. I detach in most of my studies b/c I’m constantly renaming materials (“CIP_25FA_4KPSI” for example would be cast in place, 30% fly ash, 4K PSI concrete) so that I can keep track of custom concrete mixes, different metal panel types, etc. I also often bind in the structural model and break it all down into worksets and materials that make sense to me. I would suggest, if you are not the project architect, having a meeting with the team regarding naming conventions for the materials and other possible minor changes that may come up from Tally. If you don’t change the appearance for rendering or the like, you should be able to come to an agreement where you can operate within the main model fluidly. And of course, if you’re in the design phase and doing comparative analysis (“if I change the structural bay size, how would that affect my embodied gwp?” for example) I could definitely see you staying in the central model – it’s just that the hard numbers may not be correct b/c you haven’t gotten into the concrete mixes and other items with more specificity.

As for methods to keep material mappings…you could email the support folks at Tally for a thorough breakdown. I too have had some odd experiences. The material mappings should be saved & synced to the central model and generally that’s been true. However I’ve definitely had models where somehow the connection gets lost and the mappings are gone. It’s been awhile since that’s happened – perhaps after I’ve upgraded Tally and opened an older model? I have also at times (against the IT department’s advisement) kept Tally and WBLCA models open for days to make sure that connection stays up. That’s another reason that in my detached models I try to get specific about my naming conventions for as many materials as I can – so if that happens I can remap with a bit more ease. Additionally, whenever I work a WBLCA, I always have a Word document open on the side and record my assumptions so that I can revisit them if need be. Things like – mechanically attached versus adhered roofing or the amount of rebar I’m choosing in concrete (“slab moderate” or the like) – all those assumptions in Tally that I admittedly don’t always know the answer to and may not be able to track down. They may not all be correct but as long as I stay consistent between a baseline model versus a design model (for, say LEED compliance), I think it works comparatively.

Bon courage,
Tom

2 Likes

Tom,

Thanks for the thorough response! Your advice is very helpful, I appreciate it. I agree it makes sense to track the information outside of Tally as you go along in the process, but it would be great to be able to keep the mapping process saved - I will update this thread if I find out any more information about this.

As for the impact of changing material names, it does make sense to come up with a naming converntion for this. So the issue is more with altering the material names and the impact that this has on the coordination of the model? It does not necessarily cause any errors in Revit itself (ie an invalid material name or a material that is not recognized), but for a shared model or a model that would be linked to another, the materials would not line up?

Again thanks for spending the time to help me out!

John O

Excellent - glad it helped somewhat.

I may be misunderstanding the “mapping” process - as noted, the mappings b/w Tally and Revit are saved to the central when you sync. So your tally definitions should stay mapped to your Revit materials whenever you open up the file. If you mean across multiple projects you can map definitions in the Template file and I believe (though I don’t have a lot of experience with that option) those stay mapped with every project you open in that particular Template file. Let me know if you want to do a Zoom or Teams and screenshare - you may be describing something I’m not familiar with.

On the second point - yeah, exactly - simply a coordination issue. Sometimes I ask teams to name glazing (for example) based on the VLT so I know what’s going on in the model when I get into it. But in Tally I’d want to know if it was double-glazed, monolithic, triple-glazed, etc and would prefer to name that material accordingly. It’s in the weeds but could cause some confusion if not discussed. But yes, to my knowledge the material naming wouldn’t cause any errors in Revit by itself.

Tom,

No no, we are referring to the same thing, not trying to map across several projects, only referring to one project and one Revit central model.

Thanks again for your help!

John