You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Preserve extra_fields when add_missing_atoms is set to True #56
Hello, thank you for developing this useful project.
When using the parse function from atomworks.io.parser, extra fields will be removed if add_missing_atoms is set to True. It would be helpful if these extra_fields could be preserved, as they often contain necessary information (e.g. auth_asym_id is frequently used).
For atoms that are added because they were missing in the original mmCIF or PDB file, the corresponding extra_fields could be filled with nan or another placeholder value if the data is not available in the source file.
Would it be possible to update the behavior so that extra_fields are retained rather than deleted in such cases?
We've talked about this in the past, and certainly run into it in our own work. It's a good point. I think the behavior you suggested is reasonable -- providing a default for the extra annotations (e.g., in parse, we can already specify extra_annotations; we could extend to support pairs of (annotation, default value). We will probably get around to this within the next few months, but would also absolutely welcome a PR if you're interested in contributing! @Croydon-Brixton@RafiBrent other thoughts?
Sounds like a good feature, thanks for bringing this up! I'd say that the default should still be to remove extra_fields if no defaults are specified, to avoid unexpected behavior. But when we give the warning that the extra fields will be removed, we could also describe the procedure for specifying defaults so that users are aware of the option.
Addressed in #116. Supply defaults through ParseConfig.extra_fields, e.g. {"atom_id": {"default": -1, "dtype": np.int64}}. Existing values survive missing-atom rebuilding; added atoms receive the default. Fields without explicit defaults are still skipped during completion. Regression test and usage.
Activity
nscorley commentedon Oct 28, 2025
We've talked about this in the past, and certainly run into it in our own work. It's a good point. I think the behavior you suggested is reasonable -- providing a default for the extra annotations (e.g., in
parse, we can already specifyextra_annotations; we could extend to support pairs of (annotation, default value). We will probably get around to this within the next few months, but would also absolutely welcome a PR if you're interested in contributing! @Croydon-Brixton @RafiBrent other thoughts?RafiBrent commentedon Oct 28, 2025
Sounds like a good feature, thanks for bringing this up! I'd say that the default should still be to remove
extra_fieldsif no defaults are specified, to avoid unexpected behavior. But when we give the warning that the extra fields will be removed, we could also describe the procedure for specifying defaults so that users are aware of the option.nscorley commentedon Dec 15, 2025
This is addressed in an upcoming release
nscorley commentedon Oct 5, 2026
Addressed in #116. Supply defaults through ParseConfig.extra_fields, e.g. {"atom_id": {"default": -1, "dtype": np.int64}}. Existing values survive missing-atom rebuilding; added atoms receive the default. Fields without explicit defaults are still skipped during completion. Regression test and usage.