Optimising Phase Advance - error

Moderators: cyao, michael_borland

nkuklev
Posts: 8
Joined: 13 Aug 2019, 09:08
Location: University of Chicago

Re: Optimising Phase Advance - error

Post by nkuklev » 24 Aug 2019, 20:46

I got the same behavior with unknown tokens - traced it back to having only a single instance of a marker. Is there another syntax without '#<num>' for accessing these? I tried rpn trace mode, but it doesn't list what exactly is stored by optimizer, and 'smem' doesn't output anything from inside elegant.

As a workaround, doubling up the markers as

Code: Select all

..., MARKER, MARKER, ... 
worked

Nikita

michael_borland
Posts: 1927
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: Optimising Phase Advance - error

Post by michael_borland » 01 Oct 2019, 19:19

Nikita,

The syntax for referring to quantities at markers must always be of the form <elementName>#<occurrenceNumber>.quantity, even if the marker only occurs once.

--Michael

nkuklev
Posts: 8
Joined: 13 Aug 2019, 09:08
Location: University of Chicago

Re: Optimising Phase Advance - error

Post by nkuklev » 18 Oct 2020, 19:45

Thank, Michael.

In case anyone else finds this thread, I figured out that the problem was my assumption about <occurenceNumber> indexing. It is [0,...] and not [1,...] - that is why double markers resolved the issue, since then 2nd one of the pair matched.

michael_borland
Posts: 1927
Joined: 19 May 2008, 09:33
Location: Argonne National Laboratory
Contact:

Re: Optimising Phase Advance - error

Post by michael_borland » 19 Oct 2020, 16:57

Occurence numbers actually start with 1, not 0. So if you have

Code: Select all

M: MARK,FITPOINT=1
...
BL: line=(...,M1,...,M1,...)
The first M1 is M1#1 and the second is M1#2, etc. Referring to M1#0 should return an error.

--Michael

nkuklev
Posts: 8
Joined: 13 Aug 2019, 09:08
Location: University of Chicago

Re: Optimising Phase Advance - error

Post by nkuklev » 22 Oct 2020, 00:57

Thank you Michael - I must have mixed up my recollection.

Here is the real reason: optimization terms were generated automatically in Python code that was 0-indexed, but used last instance of the marker by default. So, adding two markers meant '<marker>#1' was generated and matched first of two actual instances in the lattice. I have since then just hardcoded '#1' and enforced unique element names during lattice export to avoid possible bugs.

Post Reply