A list for the developers of CellML tools

Text archives Help


[cellml-dev] GetNameAccordingToEncapsulationParent


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-dev] GetNameAccordingToEncapsulationParent
  • Date: Wed, 12 Jan 2011 08:01:43 +1300

On 06/01/11 08:54, Lucian Smith wrote:
> So, in cellmlx.cpp, you wrote the note:
>
> // XXX This is *not* a reliable way to get a unique name for a component
> instance,
> // because not all components in an imported model have to be imported
> (they can
> // be encapsulated underneath an imported component) - meaning that if a
> model is
> // imported twice, this function will return the same name for a component
> that is
> // imported indirectly multiple times. -- Andrew Miller
>
> about my function GetNameAccordingToEncapsulationParent. The translated
> logic of the function turned out to be erroneous, however, and I believe
> the fixed and the original version does not have the problem you mention.
> However, since you know CellML better than I, I figured I should run my
> solution by you and make sure.
>
> The basic idea behind this function is to, as the name implies, get the
> name of a submodel according to the encapsulation element that contains it
> (or the main model if it's not encapsulated). My belief is that even if
> models are imported or imported/imported, the name at the top of the
> chain, so to speak, has to be unique.
>
> This is the use of what you called 'newName' (and then discarded), but was
> actually supposed to be the return value of the function. As the new
> version of the function should make clear, the trick is to find the right
> importComponent, then get its *name*, not its reference. That name, as I
> understand it, should indeed be unique.
>
> This works for, as an example, the bugbuster model,
> bugbuster/BugbusterModel.cellml The logic here seemed to work for all the
> existing models in the database... but there may be something I'm missing.
> Does this function still have the potential to go awry?

Yes... there is no guarantee that an element which is not the top of an
encapsulation tree is imported at all to the next level.

e.g.
Model M1:
Import from M2:
Component C1 as IC1
Import from M2:
Component C1 as IC2

Model M2:
Component C1
Component C2
Encapsulation: C1 encapsulates C2.

According to your algorithm, the encapsulation parent of C2 in the
instance of M2 that IC1 is imported from is C1 (imported as IC1), and
the 'encapsulation model' starts off as that same instance of M2.
wcomponentRef is "C2". Then your algorithm proceeds to the loop:
parentel is the first import element, and the inner loop will search
for an import component with component_ref C2 ... which will fail and
trip the assertion.

Best wishes,
Andrew

>
> -Lucian




  • [cellml-dev] GetNameAccordingToEncapsulationParent, Andrew Miller, 01/12/2011

Archive powered by MHonArc 2.6.18.

Top of page