Grouped arrays in Layout XL cannot be edited for size or spacing

Hi GX,

I am not sure what the Virtuoso version is used. My version is the following:

virtuoso -W
sub-version IC23.1-64b.43

I can reproduce the issue by:

1. Make a grouparray.

2. Edit in place. And move the shape.

3. Exit the edit in place ( e.g. back to top )

4. You will find the shape will be auto-realign with its geometry center.

5. Press U, or undo now.

6. The auto re-centerize will be undo by Step 5. And now the grouparray is locked and size/pitch no long edit able.

7. To resume, edit in place and move anything. Quit the editing in place and do not undo. You will find the array is editable now.

Could you check if you have warnings in CIW when you resize the group array (actually only when increasing) like:
*WARNING* (DB-270000): dbAddFigToFigGroup: Fig already belongs to a figGroup.

and the result of:
envGetVal("layout" "keepCopiedInsideGroup")

I guess it is 't' (true).
In that case, set it to nil using
envSetVal("layout" "keepCopiedInsideGroup" 'boolean nil)

and try again, prob. the issues will vanish; you may need to resize the grouparray to 1/1 and back if this is still accessible.

My guess is that resizing the grouparray creates internal copies and with the "keepCopiedInsideGroup" option the copy already assigns a figGroup to them. Then the consecutive call to dbAddFigToFigGroup fails and leaves these copied objects somewhere inaccessible to the grouparray functionality. Therefore trying to modify elements when descending fails and/or the resizing is blocked.

I filed Case #46888799, you may request a duplicate.

Hi Henkar,

Thank you for your reply.

envGetVal("layout" "keepCopiedInsideGroup")
nil

It returns nil currently. 

And my CIW has no error message during the operation.

I was not specific before, but my previous answer actually was for the post of SimbaG.
He had the description of steps to reproduce an actual problem, which I had seen before, but it did trigger the issue for me only with the "keepCopiedInsideGroup" option. So I asked to confirm my observation.

I'm sorry if it does sound harsh, but your initial post is not really understandable and too ambiguous to answer. Although, let's have a second look. Please excuse the long post, I do not have time to make it shorter.

"How can I handle FigGroups (such as mosaics) in Layout?"

What is the meaning of "How can I handle"? What do you want to do?
figGroups and mosaics are different things, there is no "such as". These are different objects with different prerequisites, different properties and used for differnt purposes. Using these terms synonymously makes no sense.

"Is there a way to convert a FigGroup into a mosaic?"

This is quite pointless.
a figGroup is a single grouping object inside a cellview
a mosaic is an arrayed instance using the hierarchy (e.g. you need a cellview to be instantiated as mosaic)

A conversion makes no real sense, though it can be done. The answer was already given in the cited post and is to create a cellview from the figGroup content ("Use leMakeCell()"), which can then be instantiated as mosaic.
Still I do not see what you would gain.

It is however possible that we use the terms and definitions differently here, but that is just a guess. I'm quite sure to follow the terminology used in the virtuoso documentation, e.g. Virtuoso Layout Suite Basic Editing User Guide, or this overview, or with the definition of common objects, like instance, mosaic, modgen, figGroup, synchronous group, group array, etc. Maybe you could have a look, too?

The part with the 'one-off copy' is IMHO a total misunderstanding on your side.
First, the cited post was written more than 2 years ago, so it is based on functionality from before IC23.1. The only way to create arrays of objects beside mosaic/modgen was to copy them as array, e.g. select the object(s), open the copy form (keyboard 'c' for copy, then F3), fill the copies/spacing fields, and press the apply button.
This creates row*col individual "one-off copies" of the original. These can each be modified/placed/rotated/flipped independently, however, "you can't then alter the array size/spacing", as noted correctly in the cited pose, because the array is an array of manual copies. So you would need to repeat the copy operation (and delete the former copies first), or move/copy the individual elementa manually in order to change array size/spacing.

IC23.1 introduced group arrays, which implements the "concept for mosaics of figGroups" that is mentioned in the cited post but did not yet exist when the post was written.

Therefore, your questions there are pointless, you did not even understand what the cited post was about.

"...the array is flipped or rotated around its center."

The documentation explicitly describes "Orientation Patterns" for group arrays, but the origin resp. the reference point where the orientation is applied, cannot be specified, it is fixed internally (prob. centerCenter).

If you want e.g. the 9 standard values (lower/center/upper x Left/Center/Right) and maybe also absolute/relative coordinates, you should file a CCR and request that both orientation and origin could be specified in the pattern.

That re-computation is forced on modification of a group array is actually a good idea. How should the object be kept consistent otherwise? Your observation of former different behaviour suggests that this was bugged in a previous ISR and got corrected. The group array functionality is rather new, so some teething problems can be expected. The releases contain a lengthy list of fixed issues and CCRs, e.g. here for IC23.1 ISR13.

"Could you suggest a way to apply an array pattern that isn’t centered on each element’s geometric center?"

- use 'one-off copies' of the original and afterwards place each individually the way you want
- create one group implementing the subpattern and use the group array only to repeat this without requiring an own pattern
- same with instances for original and subpattern and a mosaics for the final array
- create one group array for each orientation in the pattern and place these overlapping on each other
- same with one instance for the original and overlapping mosaics for each orientation
- use one instance for the original and a modgen
- have a script generating and placing the copies
- create a pcell for either the whole thing, or just for the placement

etc.pp.