Support to relaxed scan metadata (to assist input generators)

Development
1

I am interested in adding the possibility to specify the relaxed scan parameters in a similar way as constraints are specified. Actually, I think the same constraints table could be used, adding the possibility to add scan metadata. I am working on a tentative implementation, where the constrains table now looks as follows:

image
image890Ă—532 49.3 KB

I think the placing the relaxed scan metadata in this table makes sense, as they are actually mean the use of constraints. What I am not so sure is the way to pass such extra (scan metadata) information to the CJSON file (to later pass it to the input generators). For the moment, I am considering changing the constraint entry, which may then have additional attributes. Is there any suggested strategy to deal with additional metadata associated to constraints or, more in general, to a subset of internal coordinates?

2

It looks good.

I don’t think you need “enable scan metadata” as a checkbox.

I think I’d put a combo box above the “Value” line that says “Fixed Value” or “Scan” (maybe “Range”)

Then the Value line or the Scan fields only enable (or appear) as needed.

3

Thanks for the reply. I tried this:

image
image927Ă—492 49.4 KB

What about the data structure? One possibility would be to update “constraints” entry in the CJSON file, keeping backward compatibility with the current constraint format (value, indices), but extending the format to a hierarchical structure if scan is used, e.g., with “atoms”, “type” and “range” subsections. Do you have something in mind?

1 Like
4

Yes, looks good!

There are two parts of the data structure - the CJSON and the internal code.

In the CJSON, you already have the atom indices and type. So the question is basically whether there’s a “value” key => single value constraint or a “range” key (with an array of three numbers).

Does that make sense in terms of on-disk?

For the program itself, I’d probably just tweak it, so the value is the start and if steps is non-zero, pay attention to the “end” value of the range:

// … other code
  Index m_aIndex = MaxIndex;
  Index m_bIndex = MaxIndex;
  Index m_cIndex = MaxIndex;
  Index m_dIndex = MaxIndex;
  Real m_value = 0.0; // or start value for scans
  Real m_end = 0.0; 
  unsigned steps = 0; // set to non-zero for scans

There’s probably some benefit for a command that generates explicit coordinate sets from the scans. Several people have asked, for example, to scan a few dihedral angles at once.

5

Yes, that attributes for the Constraint object makes also sense to me.

I was wondering, however, what would be the best way to build the corresponding CJSON entry to feed the input generator. Now it generates an array:

[values index1 index2 (index3) (index4)]

So, the type of constraint comes naturally from the arrays size. At this point, I was wondering if we can continue with such an scheme for scan, i.e.,

[init, end, steps, index1 index2 (index3) (index4)]

In that case, the presence of a scan would be inferred from the type of the second element (if float, it is a scan, if integer a fixed constraint). But does not look like a robust implementation (what if “1.0” happen to become “1” in the process? woudl seem a valid array, but it is not..)

The other possibility is to make each constraint entry a JSON object with “value”, “indices”, “range”, “steps”… attributes. Backward compatibility would still be possible identifying the type of JSON entry (array or “object”).

Is there a preferred way to proceed?