How to increase the number of fields for per config regularization and sparsification about quip

[noambernstein]

I thought per config regularization was of the form QUANTITY_sigma, so you’d need to go into the parser and add a new parser argument. Do you mean per config_type? If so, you can look for where config_type_sigma is split by colon in gap_fit.f95 (or a related file). But if we’re going to add more quantities to that, I’d suggest making a better encoding for dicts in CLI arts (otherwise I guess we can do something like assume that strings are keys and numbers are list elements, but that’s not clean in my opinion).

[mcaroba]

Yes, I meant per config_type quantities. Thanks, I will take a look at gap_fit.f95. And, just to be clear, we only want to make a modification for internal use, since there is a project for which we're experimenting with lots of different config types that require different regularization, I'm not suggesting to add this to master.

[gabor1]

you can always get around it but not specifying it in the command line, but process the training XYZ file, and putting the sigmas for each config (based on your scheme).

…

-- Gábor Gábor Csányi Professor of Molecular Modelling Engineering Laboratory, University of Cambridge Pembroke College Cambridge Pembroke College supports CARA. A Lifeline to Academics at Risk. http://www.cara.ngo/

On 31 May 2021, at 16:04, Miguel A. Caro ***@***.***> wrote: Yes, I meant per config_type quantities. Thanks, I will take a look at gap_fit.f95. And, just to be clear, we only want to make a modification for internal use, since there is a project for which we're experimenting with lots of different config types that require different regularization, I'm not suggesting to add this to master. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[mcaroba]

Aha, that sounds even more handy, since we already parse the database to add per-force-component regularization anyway. Is this a specific keyword (which?) in the extxyz header?

[gabor1]

yes, I think it is just sigma=“X Y Z W"

…

-- Gábor Gábor Csányi Professor of Molecular Modelling Engineering Laboratory, University of Cambridge Pembroke College Cambridge Pembroke College supports CARA. A Lifeline to Academics at Risk. http://www.cara.ngo/

On 31 May 2021, at 16:59, Miguel A. Caro ***@***.***> wrote: Aha, that sounds even more handy, since we already parse the database to add per-force-component regularization anyway. Is this a specific keyword (which?) in the extxyz header? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[noambernstein]

On Mon, May 31, 2021 at 11:01 AM gabor1 ***@***.***> wrote: yes, I think it is just sigma=“X Y Z W"

i think it’s actually energy_sigma, force_sigma etc, so you should check.

[mcaroba]

OK, so indeed energy_sigma is what we were after. This is the bit of relevant "documentation":

 call param_register(params, 'kernel_regularisation_parameter_name', 'sigma', sigma_parameter_name, &
      help_string="kernel regularisation parameters for a given configuration in the database. &
      Overrides the command line values (both defaults and config-type-specific values). In the input XYZ file, it must be prepended by energy_, force_, virial_ or hessian_", altkey="sigma_parameter_name")

Thanks @noambernstein and @gabor1