Phases - weirdness

Anyone know why this happens? Why does it behave differently with the Proposed phase?

Hey, The only thing I can think of is that when creating the fases this one was combined with another.(so its basicly two fases) Probably if you create a new fase with this name it might work.


I agree that this is odd behaviour…

I think this is likely to be because when pulling parameter values ‘by name’ there can be duplication in the names.

I would try and pull the Phase by ‘built in parameter’ I think there is a node in Archi-Lab… This is more robust.

I hope that helps,


Thanks :slight_smile: I wrote some Python that seems to have fixed it but I was wondering if this is normal/ why it does it etc.

It’s our company template so it’s on a lot of jobs so not easy to fix it if it is two phases that have merged.

1 Like

I tried it with a test phase, which I then merged with another phase, but I couldn’t replicate your results… Maybe dig around in the project parameters and see if there is another ‘Phase’ parameter assigned to your Views? Unlikely but could happen :slight_smile:

1 Like

Our BIM manager has just told me the only phase he made was the standards.
The Existing and Proposed were the Autodesk OOTB ones.

Perhaps strip the file out and upload it here for us to look at?

Strippedcentral_detached.rvt (2.4 MB)
Phases.dyn (7.4 KB)

Stripped model
Dynamo as pictured :slight_smile:


Hope this helps…



#Copyright(c) 2015, Konrad K Sobon
# @arch_laboratory,

import clr
import sys
from Autodesk.DesignScript.Geometry import *

# Import Element wrapper extension methods
import Revit

# Import DocumentManager and TransactionManager
import RevitServices
from RevitServices.Persistence import DocumentManager

doc = DocumentManager.Instance.CurrentDBDocument
uiapp = DocumentManager.Instance.CurrentUIApplication
app = uiapp.Application

# Import RevitAPI
import Autodesk
from Autodesk.Revit.DB import *
import System

view = UnwrapElement(IN[0])
paramName = IN[1]

builtInParams = System.Enum.GetValues(BuiltInParameter)
for i in builtInParams:
    if i.ToString() == paramName:
			bip = i	

id = view.get_Parameter(bip).AsElementId()

OUT = doc.GetElement(id)

You will note that this python is written to work with View Phases, other parameter values may not return an ID, which is why the archilab code accounts for various storage types:


Thanks for that.

I’d already written some Python to solve my issue (Phases - weirdness - #4 by Alien)…

But I wanted to know why it’s doing what it’s doing.

This is what I wrote btw:

I only need the name OR the Id (as long as I got the same output for each phase) so I went with the easy option. :slight_smile:

I’ve just added the ID thanks to your code (I couldn’t find the bit in the Revit API for Id before)



1 Like

Same question remains though -

WHY does it behave that way with the Dynamo nodes? :confused:

The why is pretty clear. The how is another issue. The Value out of the Element.GetParameterValueByName returns a var. So, a parameter might be a string, an integer, etc. Two of your phases are being returned as a phase element. (Revit.Elements.nknownElement) The phase in question is being returned as a String.

Honestly, I would have expected all of the Phase parameter to be returned AsValueString since you are starting with the view element, rather than a phase element. Typically, you would specify AsDouble, AsInteger, AsString, AsValueString or such. So, I think there is a bug in the node that isn’t parsing the value to the correct type. Returning an element from a parameter value would be a non-typical thing to return - unless the node were to look at the Storage Type. Or rather with the current release of Revit,the ForgeTypeId.

I think the question is how the node is parsing the input to determine the correct var output type. In this case it is unpredictable - at least in this file. I haven’t been able to replicate the issue in other files with Revit 2023.

I think you’re answering why the last node doesn’t work when it’s fed a string.
That, as you say, is pretty clear.

I want to know why the, ‘Element.GetParameterValueByName’ node sometimes spits out a string.
That’s what I’m asking. It is a very odd glitch!

Without seeing the code behind the node - hard to say. Revit has a lot of elements and parameters. I’m guessing this node is written to parse standard user defined parameters that fall into easily determined type categories. The node probably needs an input so you can manually force the correct data output rather than var. With var - you are at the mercy of the node’s code.

You’re on a version of Revit as ForgeTypeId was becoming a thing. This is one of those programmatic things that ForgeTypeId is trying to clear up.

how long has this file been around? It could be that this element is from a very old version of Revit and something is not quite right under the hood. This Phase has an element Id of 0. I think that is unusual. If I get rid of this phase (merge with previous) and replace it with a new one - the problem goes away. And I haven’t been able to recreate the issue with other files in Revit 2023. So, something about that particular phase and the node are not playing well together.

Good point about how long it’s been round. Our BIM manager tells me it’s inherited from previous BIM manager but updated. So in theory it could be over 7 years old… but upgraded several times.

I wonder if there’s a fix for that.

I did an audit, but that had no effect.

Hello, i had a similar issue but relating to the Element.getparametervaluebyname.
Instead i was shown to parameter.getparametervaluebyname which worked wonders!

Hope that helps :slight_smile:

1 Like

The short answer is it’s a bug. It’s not supposed to behave that way. The real question, which I don’t remember if it was ever determined or not, is whether this is an issue on the Dynamo side or the Revit side.

Either way, it doesn’t really matter. In this version, the node is not consistent when returning Phases. In subsequent versions the issue (as far as I’m aware) has been fixed. As you’ve shown, the API is always an option so there are still “workarounds”.

1 Like