mikeheiber / excimontec Goto Github PK

This will likely improve visibility and make it more official. What do you think @MikeHeiber ?

This file will contain instructions for potential developers so consistent coding standards can be followed.

This will help keep the style of the source files consistent to add clarity and readability.

Currently if slurm is not installed system_test1.sh will not run.

Add tests that import sample morphology files from Ising_OPV v3.2 and 4.0 in both compressed and uncompressed format, and make sure that errors are produced with invalid morphology files.

It would be nice to be able to perform off-lattice simulations that can include positional disorder, either random positions or using site coordinates from molecular simulations.

Add a test_morphology.txt BHJ morphology file generated by Ising_OPV to the test directory and write unit tests for importing the morphology data.

Output the Fermi energy, transport energy, and equilibration energy each with and without the Coulomb potential energy included.

Add event for transition from triplet charge transfer states to triplet exciton states on donor or acceptor sites.

Add events for the injection of polarons from the electrode contacts and calculation of image charge interactions.

The correct copyright notice should cover 2017-218 instead of just 2018. This needs to be updated in all files.

update Excimontec to use latest master branch version of KMC_Lattice

Update KMC_Lattice submodule to latest development branch version and update derived Event classes in response to the new default calculateRateConstant function in the Event class.

In the steady-state transport test, the integral of the DOS and DOOS are not always correct (= equal to the total number of sites, resp. carriers in the simulation). When using the attached job and parameters, the integral over DOOS is correct (=1e19 cm-3), but the integral overt the DOS is too low by a factor of 1.1 (but I've seen larger deviations, up to 2).
4929459.zip

Parameters class needs to eventually have this capability to enable backwards compatibility with old parameter file formats.

Write documentation for all classes and their public functions.

Would be great if the code could also do periodic boundary conditions in all three directions to calculate mobility in steady-state. That plus output of the Fermi energy and the transport energy would make it suitable for organic thermoelectrics.

See some discussions here:
travis-ci/travis-ci#6300

See some Travis CI documentation here:
https://docs.travis-ci.com/user/docker/

This is a safety issue, controlling the scope of the functions and classes will help prevent conflicts in the future.

Redirect cout buffer to stringstream during testing to suppress excessive command line output during testing.

The OSC_Sim files are a little bloated. Readability can be increased by better modular design moving the Parameters class into its own file would be one to do this. It would also be beneficial to get rid of all the members of the OSC_Sim class that refere to the parameters and just make a Parameter Object a member of the OSC_Sim class this would vastly reduce duplication.

Use weighted average method to determine the transport energy over each time interval of the transient

Add project name EXCIMONTEC prefix to header guards to make them more unique.

As the project it will be hard to maintain individual make files. It would be better to switch over to cmake which is better able to handle large projects.

Add a document with guidelines for how other developers can contribute to the project, including coding style, workflow details, and testing requirements.

• Requesting features and reporting bugs
• Making Tutorials
• Forks and feature branches
• Code testing
• Pull requests
• Standards and code review

At the end of the IQE test, once exciton generation stops, if there are only trapped charges left, the situation can arise where there are still charges trapped in the simulation box, but no possible events. Currently this produces an error, but this situation should be handled without generating an error.

Add periodic generation of a checkpointing file that contains all information about the state of the simulation, so that if the compute job dies, it can be continued later.

Functionality needs to be added to be able to import custom energy landscapes to run KMC on. This will be done by loading files in a similar manner to the topology.txt files.

Need to update the Exciton and Polaron classes, their derived Event classes, and the OSC_Sim class to utilize the new BKL algorithm that has been implemented into the development branch KMC_Lattice.

When executing 'make clean', the Excimontec build is correctly cleaned, but the submodule KMC_Lattice build is not also cleaned. One could navigate into the KMC_Lattice dir and clean the build there, but it seems better to just have the regular 'make clean' clean up the KMC_lattice submodule build files also.

User would specify the hole dopant density and dopant LUMO energy. Then, the simulation could randomly place fixed negative ionic dopants in the lattice and modify the energies of the sites surrounding the dopant sites using the calculated Coulomb potential energy. The lattice would then be initialized with hole polarons on the dopant sites.

Generate a warning to users if they build the Excimontec and try to run calculations without first running the tests on their computing system.

Write a simple tutorial and demo that shows how to run ToF simulations and provides examples of the types of data and information produced by the simulation.

• Neat film with different internal potential values using uncorrelated Gaussian DOS
• Neat film with different magnitudes of disorder using uncorrelated Gaussian DOS
• BHJ films with different magnitudes of tortuosity due to anisotropy (from Ising_OPV) using uncorrelated Gaussian DOS

Derived event classes only make sense in context of the object itself, so it would be better to nest them as public classes within their associated object. For example, all exciton events should be nested into the Exciton class.

Use MS Visual Studio for set the format of all source code and testing files.

Add more unit tests to increase code coverage of tests.

Hello everyone!

I would like to import uncompressed morphologies for Excimontec, generated with Ising_OPV.

I generated several morphologies, with many MC steps (of the order of 100000), and when I imported them into Excimontec I realized that I put them to save the uncompressed files, so I could not import them into Excimontec. I did not want to have to redo the morphology. Is there any way to import uncompressed files? Or some way to convert the uncompressed files to compressed.

Thank you!

Currently the energies are calculated relative to the mean of the DOS, but this formulation breaks down when polarons may hop between donor and acceptor sites that have different mean site energies. As a result, the energy calculations must include the HOMO or LUMO of the sites to account for hoping to sites that have different HOMO or LUMO.

Create separate class for importing and error checking different types and versions of parameter files.

Ideally this class or file would control all functionality associated with versioning. E.g.

Version.h

namespace Excimontec {
  class Version {
    private:
      int major_ = 1;
      int minor_ = 0;
      int bug_release_ = 5;
      std::string release_type_ = "beta";
    public:
      const int getMajor(){return major_;}
      const int getMinor(){return minor_;}
      const int getBugRelease(){return bug_release_;}
      const std::string getReleaseType(){return release_type_;}
      const std::string getVersion(){
        return "v"+to_string(major)+"."+to_string(minor)+"-"
          release_type_+"."+to_string(bug_release_);
      }
  } version;
}

Some thing like this it would also be useful if the class also had functionality for dealing with translating a string into a version. For instance if you want to check if a file output by the OSC_Sim code is still compatible with the current version. This will also make it easier to compare the releases if you easily grab the integer values of the major and minor releases.

Also when implementing cmake the versioning can then also be controlled easily using cmake variables.

Version.h.in

namespace Excimontec {
  class Version {
    private:
      int major_ = @MAJOR@;
      int minor_ = @MINOR@;
      int bug_release_ = @BUG_RELEASE@;
      std::string release_type_ = @RELEASE_TYPE@;
    public:
      const int getMajor(){return major_;}
      const int getMinor(){return minor_;}
      const int getBugRelease(){return bug_release_;}
      const std::string getReleaseType(){return release_type_;}
      const std::string getVersion(){
        return "v"+to_string(major)+"."+to_string(minor)+"-"
          release_type_+"."+to_string(bug_release_);
      }
  } version;
}

You could even overload the < and > to easily compare if a version is newer.

Need to add new parameters enabling the interfacial energy shift, and an energy shift factor to control the magnitude of the energy shift

Initial files for running system batch submission tests along with a series of test parameter files are not currently being used and add cluster to the repo. These files should be removed and left out of the release until the features are working correctly.