Markus
Markus

Reputation: 13

Disabling variables in connector depending on boolean

I'm building electrical models that use a complex number or just the real part of a variable in a connector. Depending on a boolean I am switching between the two equation sets. My question is: What is the best way to handle the imaginary when I don't want to use it. Setting it to zero leads to problems when I connect other components that do the same because the variable is overdetermined. Is there a way to disable the imaginary part or change the connector so it only has a real variable if I use the real valued equation set? Below I pasted the equation set.

equation 
   if transient then
     v = Complex(Vnom*cos(theta + phiV),0); // how can I avoid setting im to zero here?
   else
     v = Complex(Vnom*cos(phiV), Vnom*sin(phiV));
   end if;

Thank you in advance for your help!

Upvotes: 1

Views: 139

Answers (1)

Michael Tiller
Michael Tiller

Reputation: 9421

There is actually an analogous issue in both fluid problems and multibody problems. In the fluid case, the "equation of state" changes which influences how many degrees of freedom there are. In the case of multibody systems, you have the issue that you need some kind of mechanical ground element but if you have a "loop" in your components it will be over constrained.

It seems to me your issue is closer to the fluid problem (but I don't now the AC domain well at all, so I'm just guessing). In that case, what you can do is cascade down through the hierarchy information about exactly what kind of formulation to use. If you want to use different connectors, then you use a replaceable package to cascade new connector types through the hierarchy. This gets kind of involved. If, however, you just want to know whether to use one equation or the other (across a bunch of components), then you can just cascade a (Boolean?) parameter value through everything (e.g., your transient flag).

Another thing you might consider is using inner and outer to implicitly cascade a parameter through your hierarchy. Several libraries use a so-called world object to provide global information about the model. In this way, you can put an inner world object at the root and all components within the same hierarchy can access it using the outer keyword. I try to avoid inner/outer and use the more explicit parameter cascading. But it is up to you.

Upvotes: 2

Related Questions