Re: Hierarchical references

Hi David,

The same issue did come up in the committee meeting today with respect 
to the access of the variable value. (I apologize that I didnt get some 
of the names clearly and whether you were also involved in that 
discussion in the call, but here is the update from the meeting).

* It seems fairly unclear about the usage of the variable access from an 
user point of view - whether they want the "last accepted timepoint" or 
"the latest iteration value" in a NR iterations. There seems to be 
ambiguity in either of the choices (and i agree probably the reason for 
restricting in the language) since there is no guarantee in order of 
evaluation of the instances if you take the last iteration value or not 
reflecting the strobe values if we go with accepted timepoint value 
which might be quiet confusing.

* One of the use cases has been to have a file descriptor open and refer 
to that variable using OOMR. However, with the proposal of analog 
initial block the same feature can be achieved more cleanly through this 
mechanism.

* As part of the discussions in the call, the plan was to send out an 
email to the reflector (which i guess is this email), to seek for any 
examples or models that use OOMR access for variable, the intention and 
what the modeler expects in terms of the value of the variable.

So if any of you have any good examples of such an usage please post it 
to the reflector. Otherwise, the current plan is to disable to access of 
variables using out of module access.

Regards,
Sri


David Sharrit wrote:
>> When accessing variable values and probes on named branches the value as
>> per the last iteration shall be returned (to avoid race conditions) and
>> without affecting any partial dependencies. 
> 
> Perhaps I'm just confused, but even after I consider this to just be talking
> about variable values, I'm still uncertain and concerned as to what this is
> really trying to do or provide.  What exactly is the "value as per the last
> iteration"?  Presumably that is, or could be, the previous time point value
> in a transient simulation.  For a time varying variable, will that not
> result in fairly unpredictable and inconsistent results, as it will depend
> on the particular timestep involved? And what does it even mean for other
> analysis types, such as AC or HB or even DC?  Without derivative
> information, it seems you could either be introducing convergence failures
> with incorrect Jacobians, or inconsistent (incorrect) results, with state
> variable dependencies seeming to exist in transient simulations but not in
> AC simulations.
> 
> It seems there were some major reasons why OOMR access to variable values is
> disallowed in the present LRM, and I don't yet see how these issues have
> been cleanly, accurately or practically resolved.
> 
> David
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.