This week, as my mentor suggested, I was working on testing pyseams on linux in the cloud with the help of github actions. While doing that it came to my attention that the function named "keepAxialRingsOnly" is unused and not defined in any file but it is declared in "topo_one_dim.hpp". I created an issue about it here

Check-in Questions

What did you do this week?

1. Ran a basic test in github for pyseams.
2. Created an issue for an unsued function.
3. Started working on atomic visualizations
4. Was reading the d-SEAMS paper to write the lua workflow

What is coming up next?

1. Running the dSEAMS workflow in python
2. Visualizing it.
3. Adding pytests.

Did you get stuck anywhere?

No, I wasn't stuck anywhere. My meetings with my mentors are regular and frequent which helps me to clear my doubt ASAP.

This week I wrote function bindings for functions in the namespaces sinp, nneigh, bond, primitive, ring, tum3 and gen. I made some commits as well over in pyseams. I worked a little bit on string representation for users while using the dSEAMS in python, it looks like this but this would be confusing for the users  as the representation was <build.cyoda.pointdouble 0x7fbab9a75a30="" at="" object=""> </build.cyoda.pointdouble>which is terrible in lists.

So, we changed it to <pointdouble mem_loc:1eb6b20=""></pointdouble> by using this:

.def("__repr__", [](const molSys::Point<double> &a) {
std::uintptr_t ptr_val = std::uintptr_t(&a);
return fmt::format("<pointdouble mem_loc:="">"</pointdouble>, static_cast<uint>(ptr_val));
.def("__str__", [](const molSys::Point<double> &a) {
return fmt::format(
"x: {} y: {} z: {} type: {} molID: {} atomID: {} inSlice: {}",
a.x,
a.y,
a.z,
a.type,
a.molID,
a.atomID,
a.inSlice);
});</uint>

this looks more clear and specific. It also allows for users to get the memory location fairly easily if needed with aa.pts[0].split(':')[:-1].

Since we implemented __str__ as well, by using the following command, they can get more information by calling str() on a PointDouble.

However we might change this to expose a print() or info function instead.

Check-in Questions

What did you do this week?

1. python bindings for functions. The following are the commits made in response to that.

   1. commit 1.
   2. commit 2.
   3. commit 3.
   4. commit 4.
   5. commit 5.
   6. commit 6.
   7. commit 7.

   What is coming up next?

   1. Writing python scripts

   2. Writing pytests
   3. More repr and str work

   Did you get stuck anywhere?

   No, I didn't get stuck anywhere.

Overview

This week I was rather unwell. However, I spent my time going over python packaging rules for eventual distribution via PIP, and I looked into alternate ways to fill in the core `yodaStruct` object because of segfaults in d-SEAMS. I am splitting my time now between the C++ core (with my mentor mostly) and the Python (pure and Pybind11) bindings.

Check-in Questions

What did you do this week?

- Moved `pyseams` into the d-SEAMS organization

- Looked into `ase` atoms and how to read an `xyz` in Python to populate a`yodaStruct`

- Discussed the (re-)design of the readers in D-SEAMS for the bindings

- Started writing some basic `pytest` fixtures, since the data needed will have to be shared across tests

What is coming up next?

- More re-writing of the C++ core

- Adding more tests and continuous integration (I was asked to look into this)

- Understanding more of `ase` and how the Atoms class maps to the d-SEAMS yodaStruct

Did you get stuck anywhere?

No, I was not well, and couldn't raise any PRs this week, but I'm on track, and have discussed the next steps with my mentors.

Overview

This week I spent a lot of time on debugging issues with pointers in d-SEAMS. As noted on the issue I opened and discussions with the core-team, some refactoring is required which I began working on in tandem.

Check-in Questions

What did you do this week?

1. Worked on binding the functions for input in d-SEAMS

2. Opened an issue to discuss issues with the code: https://github.com/d-SEAMS/seams-core/issues/35

3. Added bindings and cleaned up https://github.com/RuhiRG/pyseams for migration.

4. Opened a pull request to seames-core : https://github.com/d-SEAMS/seams-core/pull/36

What is coming up next?

1. More fixing of the d-SEAMS core

2. Add bindings and fix build

3. Setting up an issue with the order in which I will implement the bindings

Did you get stuck anywhere?

I was able to meet my mentor and the project organisers.  Pointers and their usage are a bit confusing to me so far.

Overview

This week I started by making a github repository named pyseams. Me and my mentor worked together on writing a meson build file. After this, I realised that dSEAMS had some enums which had to be converted to enum class to prevent the implicit conversion to other types i.e., to another enum or int and made a pull request for the same thing. Then I proceeded with writing bindings using pybind11, tested it locally, and committed to the git repo pyseams.

// The following bindings are still in progress:

#include <pybind11/pybind11.h>
#include "../subprojects/seams-core/src/include/internal/mol_sys.hpp"

namespace py = pybind11;

PYBIND11_MODULE(cyoda, m) {
  py::class_<molSys::Point<double>>(m, "PointDouble")
          .def(py::init<>())
          .def_readwrite("c_type", &molSys::Point<double>::type)
          .def_readwrite("molID", &molSys::Point<double>::molID)
          .def_readwrite("atomID", &molSys::Point<double>::atomID)
          .def_readwrite("x", &molSys::Point<double>::x)
          .def_readwrite("y", &molSys::Point<double>::y)
          .def_readwrite("z", &molSys::Point<double>::z);

  py::enum_<molSys::bond_type>(m, "BondType")
          .value("staggered", molSys::bond_type::staggered)
          .value("eclipsed", molSys::bond_type::eclipsed)
          .value("out_of_range", molSys::bond_type::out_of_range);

  py::enum_<molSys::atom_state_type >(m, "AtomStateType")
          .value("cubic", molSys::atom_state_type ::cubic)
          .value("hexagonal", molSys::atom_state_type ::hexagonal)
          .value("water", molSys::atom_state_type ::water)
          .value("interfacial", molSys::atom_state_type ::interfacial)
          .value("clathrate", molSys::atom_state_type ::clathrate)
          .value("interClathrate", molSys::atom_state_type ::interClathrate)
          .value("unclassified", molSys::atom_state_type ::unclassified)
          .value("reCubic", molSys::atom_state_type ::reCubic)
          .value("reHex", molSys::atom_state_type ::reHex);

  py::class_<molSys::Result>(m, "Result")
          .def(py::init<>())
          .def_readwrite("classifier", &molSys::Result::classifier)
          .def_readwrite("c_value", &molSys::Result::c_value);
}

Check-in Questions

What did you do this week?

1. Made a Github repository named pyseams.

2. Pull request for enum to enum class change.

3. Made a meson build file.

4. Started compiling the extensions and running the python bindings.

What is coming up next?

1. Finishing the python bindings for the first workflow in the lua design as discussed earlier.

2. Writing documentation and tests

3. Moving the pyseams repository to the dseams-core.

Did you get stuck anywhere?

I was a bit stuck at the meson build file process, but my mentor helped me with it. I think I am on track.