What parts of a component instance should COPY include?

[g5t]

The 'McCode' grammar includes the possibility to define a component instance from another component instance defined earlier in the Instr file; e.g., from the ILL_H22_VIVALDI example instrument

...
COMPONENT Environment_in=PowderN(
  radius = 0.05, yheight = 0.1, thickness=0.002,
  reflections="Al.laz", concentric=1, d_phi=RAD2DEG*atan2(0.5,L3),
  p_transmit=0.95, p_inc=0, barns=1)
  AT (0, 0, 0) RELATIVE SamplePos
EXTEND %{
  flag_env=SCATTERED;
%}
...
COMPONENT Environment_out=COPY(Environment_in)(concentric=0)
  AT (0, 0, 0) RELATIVE SamplePos
EXTEND %{
  if (SCATTERED) flag_env=1;
%}
...

The resulting Environment_out component instance has all of the same parameter values as Environment_in with the exception of concentric which is updated to be 0.
Depending on how closely you've looked at instrument.y, you may or may not be surprised to learn that the EXTEND code block of Environment_out is

if (SCATTERED) flag_env=1;

not

flag_env=SCATTERED;
if (SCATTERED) flag_env=1;

(like I erroneously believed).

The current question is not so-much about whether the current behavior is 'right' in this case, but rather in the case where Environment_out does not define an EXTEND block of its own. In such a case, you might expect the instance to have no extend statement but in the current implementation it has the same extend block as Environment_in.

The current implementation in fact sets all of the following to the same reference

• EXTEND
• GROUP
• JUMP
• WHEN
• METADATA
  when COPY is used, which might be surprising to some users.

@willend @farhi @mads-bertelsen:
Is this the generally understood and preferred behavior for the COPY verb?

[farhi]

Hi Greg @g5t , I think the behaviour you mention dates from when I pushed the COPY stuff. Indeed, seen from today's perspective,it would probably make sense to either not copy, or at least explicitly print-out what is actually copied, so that there is no surprise.
I think the copy of the JUMP, WHEN and EXTEND blocks may be justified in the case we have numerous guide elements which e.g. would rotate and possibly count the number of interactions on surfaces. The best, in order to revamp this use, is to envisage a number of use-cases.

So, basically when do we actually COPY ?

• guide elements, rotated (but the AT, ROTATED blocks are currently not copied in fact).
• material components before/after the sample (e.g. sample environment)
• plenty of detectors arranged in arrays
• a set of "parallel" pathways in a GROUP (e.g. two guide channels)
• a multi-material sample stack/array
• ...

and for each, what do we expect in terms of grammar ?
My 2c.

[willend]

@g5t @farhi,

To me personally, my thinking of the current practical use of COPY is that it should:

• Copy the instance, i.e. Component_class(parameters=values)
• Allow to overwrite some (parameters=othervalues)
• Naturally disregard AT, ROTATED as we generally don't let components "overlap"
• Disregard "anything else that makes the instance special" - to me specialities includes the EXTEND %{%}. Also from the point of view that both COPY and EXTEND are regarded "advanced grammar" and thus the usage should (in my preference) be explicit.
• In the same line of thinking JUMP and WHEN should not be copied. The picture to me becomes slightly more blurred for GROUP, but the argument could be to also require "making GROUP explicit"

To me "keeping usage simple" means copying Component_class(parameters=values) only and allowing overwrites by (parameters=othervalues). Letting the examples serve as a reasonable sample of "current practical usage", we could try to investigate if any COPY there uses an implicitly defined EXTEND, GROUP, WHEN or JUMP?

[willend]

(BTW @tkittel mentioned that a "fair" way to proceed would be to keep the "vanilla" McCode implementation as is - but raise a warning when "overwriting" a copied EXTEND block)

[willend]

@g5t could you add another voting option for "Keep McCode implementation as is, but add a warning when overwriting an EXTEND block" ?

[g5t]

Yes, if anyone voted previously though they will need to re-vote now however.

[farhi]

I don't know how the vote works, but I choose "keep as it is today, and add warnings when over-writing".

[tkittel]

I voted, but ultimately I don't have a strong opinion :-)

[g5t]

Adding a warning is the unanimous decision. @willend did you have an idea how to do that?

[willend]

I've put together #1786 which does this for the explicitly discussed COPY + EXTEND scenario. The question is then if we want something similar or different for other things like JUMP, WHEN and GROUP?