ges-compchem / ges-comp-echem Goto Github PK

Add an example to the user guide and prepare the proper API entry

Implement a viewer/renderer to plot a ball-and-stick version of a molecule colored according to a list of generic values. If possible implement labels on the atoms to report the values.

In version 0.3.0 the MPI_FLAG variable was used to globally set the MPI-based software behavior. However, when setting the variable in a job script, the options set by the user are ignored.

We should discuss how to improve the interface of reading and generating cube data.

If the save_cubes flag of orca.spe is set to 'True', then the binary content of the gbw file might be saved into the System instance.

We might implement a wrapper for orca_plot, and then use the relevant functions to implement properties of System instances such as e.g. system.spin_density to generate cubemaps on the fly. This prevents the use of explicit file names of temporary files to read and manipulate cubes.

Implement CPK like coloring scheme

Implement a function in the vmdtools.py module to render spin density cube files using VMD.

Library should be able to correctly generate a System object starting from a program (like Orca or xTB) output file. This is already somewhat implemented in the parse_output functions in the various Engines but it needs to be generalized.

Possible pre-made solution ready for integration: morfeus

When rendering condensed Fukui functions using VMD the labels of the condensed Fukui values are covered by the 3D objects. The labels appear to be fixed in a 2D plane perpendicular to the viewer point of view with its origin fixed on the coordinates of each atom. As such, the atom itself covers the label. So far I only managed to apply an offset in the XY plane.

If possible the label should appear on top of the 3D representation of the atom like, for example, in chemcraft.

e.g., if the alternative GEPOL-SES scheme needs to be invoked:

%CPCM
  SMD True
  SMDsolvent "water"
  SurfaceType gepol_ses_gaussian  # <---
end

Since the default option is the vdW gaussian scheme...

%CPCM
  SMD True
  SMDsolvent "water"
  SurfaceType vdw_gaussian  # <---
end

...for the time being we can just add a flag in the Engine init, but I don't like this approach, we should implement a customizable %CPCM block like we're doing for SCF and GEOM

Implement unit testing for covering missed updates such as this, in oneeloxidation.py:

while pKa < 20:

        deprotomer_list = crest.deprotonate(currently_protonated, nproc=nproc)

        if type(method) != XtbInput:
            deprotomer_list = tools.reorder_energies(
                deprotomer_list, nproc=nproc, method_opt=xtb, method_el=method, method_vib=xtb,
            )

        if deprotomer_list:
            currently_deprotonated = deprotomer_list[0]

        # if deprotonation is unsuccessful (e.g., topology change), save the molecule but with
        # sentinel values for pKa (which cannot be calculated)
        else:
            mol_list.append([currently_protonated, None, None])
            break

Where this block:

else:
            mol_list.append([currently_protonated, None, None])
            break

Should have been this:

 else:
            currently_protonated.properties.pka[method.method] = None
            mol_list.append(currently_protonated)
            break

Desired features:

1. Create a constants .py module to store and organize all the numeric constants, dictionary and conversion factors
2. Store the coordinates in numeric form within the System object instead of strings
3. Implement save and load functions in the System object to allow the export of all the data in .json format (Ensuring the back-compatibility for future System objects)
4. Define a VMD-based tool to export data in image format and define a separate module
5. Refactor the save cube option in the orca wrapper to allow for more flexibility in selecting the volumetric data to be saved

Other ideas:

1. Implement custom check to verify if the required program is available. (e.g. check if orca is available before moving to the system(...) call)
2. Define a new parser of the orca output file to load many properties in one run (e.g. join final single point energy, search of mulliken charges etc.)
3. Define a more structured form of the properties to be stored to avoid confusion on the format.

To do:

• Update the documentation accordingly

To be discussed:

• Referencing a config.txt file created by the user to set all the paths to the required programs (The config.py can be used to read the paths or automatically read the default ones available on the system. I would avoid any reference to explicit paths in the package.)
• Final conversion of the package in a pip-friendly format and release on PyPI

config.get_ncores() calls from within the modules need to be moved to the function calls (spe, opt, etc.) and not in the initialization of the class instance.

What if we add:

if os.environ["OMP_NUM_THREADS"]: # or "== Value" I don't know what's the default if it is not set, 
    self.nproc = int(os.environ["OMP_NUM_THREADS"])

I think it should work

Implement transition state optimization, NEB and IRC algorithms. Implement tools to process the output data, test and update documentation.

The routine fails if the conformer_search and tautomer_search flags are set to False. It detects every molecule as dissociated.

Implement an error detection procedure to detect a system job that exited abnormally. For example, when orca fails, no "Normal termination" should be found in the output file. If the error is detected it can be reported to the user in a more self-explanatory way than some random exceptions raised during the parsing phase.

Implement inplace option for calculators

(see job-dispatcher for reference)

The developer's guide should integrate the already existing documentation with:

• Codebase Overview: Start with a high-level overview of your codebase. Describe the purpose of the library, its main features, and how it is structured at a high level. This includes the main modules, classes, and their relationships.

• Directory Structure: Provide a clear explanation of the directory structure of your codebase. This should include the purpose of each directory and the type of files that can be found in them.

• Key Components: Identify the key classes, functions, and modules in your codebase. For each of these, provide a brief description of its purpose, how it works, and how it interacts with other parts of the codebase.

e.g. If method is CCSD(T) the () must be removed from file name

Molecule objects should be able to accept .gen files as input, besides .xyz files

https://xtb-docs.readthedocs.io/en/latest/properties.html?highlight=cube#cube-files

Implement option to save certain files (maybe meeting certain extensions) after a job is done.

Desired features:

• Implement an engine for NAMD
• Refactoring and re-deploy of MDTrajectory class for NAMD and DFTB+
• Proper definition and placement of the velocity property and related quantities