Hi @jmmiller
This is an interesting problem - thanks for reporting it. So first off, Element.IntersectsElement node does support elements from linked files (per se) as you’ve rightly pointed out. Which raises the question then, why is it not working? Well, I’ve investigated and found the source of the problem, which points towards a major limitation within Revit (as opposed to a bug).
The problem is caused by the way Revit, and therefore the API, locates linked documents - it will always locate them in their Original Location (lets call this OL) relative to the file centre (XYZ 0,0,0) even if the link has been moved, rotated or mirrored.
Given that in 90-99.9% of cases, a linked document will be moved to align with your own model, what this means is, that while elements from a linked document may appear visually to be aligned with the live elements in the active document as you’ve observed, in the API context, they are actually positioned back at the OL, so the intersections fail, and this is why you are seeing zero results from the Element.IntersectsElement.
The smaller the move (or if there is no move at all), the more disguised the problem then, which is why its easy to mistake the node as working as @john_pierson has assumed with the Rhythm node - it too does not support elements from linked documents for the same reason. “Testing leads to failure, and failure leads to understanding” - useful words of wisdom from Burt Ruten!
To illustrate the limitation, here is a test file with a few walls with the OL shown in blue:
When the document is linked into a new file relative to some live ducts in the active document, its default position (Origin-to-origin) is the position the API always uses to locate its elements, as illustrated below. The linked elements bounding boxes are shown in blue - notice they don’t move regardless of what changes are made to the location of the link instance from which they derive. Hence, they ducts are in one Cartesian context, whereas the linked elements are in another even if they moved to the same context as the ducts, and that’s the cause of the problem:
What can you do then? Unfortunately not a lot: either wait for a fix or create a temp Revit file and bind all links! There is good news though, I’ve already developed a workaround which is currently going through testing and will be published to BimorphNodes in due course (there are lots of tests to perform, and its not trivial). Here’s a sneak peak testing the algorithm I’ve developed which locates the position of linked elements regardless of translation or transformation.
In answer to your other question re IFC, so long as the IFC content has been imported as Revit elements, then the Element.IntersectsElement node will work. If you want to double-check, use the Element.IsElementSupported node.