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.
Heya,
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,
Mark
Thanks 
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
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?
Hey,
Hope this helpsā¦
Cheers,
Mark
#Copyright(c) 2015, Konrad K Sobon
# @arch_laboratory, http://archi-lab.net
import clr
import sys
clr.AddReference('ProtoGeometry')
from Autodesk.DesignScript.Geometry import *
# Import Element wrapper extension methods
clr.AddReference("RevitNodes")
import Revit
clr.ImportExtensions(Revit.Elements)
# Import DocumentManager and TransactionManager
clr.AddReference("RevitServices")
import RevitServices
from RevitServices.Persistence import DocumentManager
doc = DocumentManager.Instance.CurrentDBDocument
uiapp = DocumentManager.Instance.CurrentUIApplication
app = uiapp.Application
# Import RevitAPI
clr.AddReference("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:
https://github.com/ksobon/archilab/blob/master/archilabSharedProject/Revit/Elements/Parameter.c
3 Likes
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.
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? 
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
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