Use phase class2 #205

CSSFrancis · 2024-04-12T22:53:39Z

Description of the change

This simplified the commit history for #201 and focuses the scope of the PR. Hopefully that makes it (slightly) more manageable when checking/merging.

Progress of the PR

Docstrings for all functions
Unit tests with pytest for all lines
Clean code style by running black

Minimal example of the bug fix or new feature

>>> from diffsims.utils import sim_utils
>>> # Your new feature...

For reviewers

The PR title is short, concise, and will make sense 1 year later.
New functions are imported in corresponding __init__.py.
New features, API changes, and deprecations are mentioned in the
unreleased section in CHANGELOG.rst.
Contributor(s) are listed correctly in credits in diffsims/release_info.py and
in .zenodo.json.

CSSFrancis · 2024-04-20T15:24:29Z

@viljarjf, can you review this? It seems like we should get this in, and then we can work on getting the rest of diffsims ready for a release.

viljarjf

Looks good! See comments for some minor things. I did not go through all the tests very thoroughly, but they all pass at least.

diffsims/generators/simulation_generator.py

diffsims/simulations/__init__.py

viljarjf · 2024-04-21T08:56:52Z

diffsims/simulations/simulation2d.py

+    phases : Sequence[Phase]
+        The phases in the library.


Suggested change

phases : Sequence[Phase]

The phases in the library.

simulation: Simulation2D

The simulation to get from.

viljarjf · 2024-04-21T08:57:06Z

diffsims/simulations/simulation2d.py

+    phases : Sequence[Phase]
+        The phases in the library.


Suggested change

phases : Sequence[Phase]

The phases in the library.

simulation: Simulation2D

The simulation to get from.

diffsims/simulations/simulation2d.py

viljarjf · 2024-04-21T09:25:38Z

diffsims/simulations/simulation2d.py

+            return copy.deepcopy(self.coordinates)
+
+    def get_current_rotation(self):
+        """Returns the matrix for the current matrix"""


Suggested change

"""Returns the matrix for the current matrix"""

"""Returns the matrix for the current rotation"""

diffsims/tests/generators/test_simulation_generator.py

viljarjf · 2024-04-21T09:42:41Z

diffsims/utils/shape_factor_models.py

+    for i, (excitation_error_i, r_spot_i) in enumerate(zip(excitation_error, r_spot)):
+
+        def integrand(theta):
+            # Equation 8 in L.Palatinus et al. Acta Cryst. (2019) B75, 512-522
+            S_zero = excitation_error_i
+            variable_term = r_spot_i * (phi) * np.cos(theta)
+            return shape_function(S_zero + variable_term, max_excitation, **kwargs)
+
+        # average factor integrated over the full revolution of the beam
+        shf[i] = (1 / (2 * np.pi)) * quad(integrand, 0, 2 * np.pi)[0]


This can be vectorized with quad_vec, but that can wait

Let's make an issue for this and we can handle this later.

setup.py

CSSFrancis · 2024-04-21T14:28:31Z

@viljarjf This should be better now based on your comments. Thanks, let me know what you think and maybe we can merge this?

viljarjf

I think this can be merged :)

hakonanes · 2024-04-21T15:57:07Z

I'd like to review it given it touches on ReciprocalLatticeVector, which is heavily used in kikuchipy workflows. I'm not so sure about the intensity parameter.

hakonanes · 2024-04-21T15:57:24Z

I can review within the next few days.

hakonanes · 2024-04-21T16:05:24Z

So, sorry about the hold-up, @CSSFrancis.

Couple of questions right away:

Could you explain the reason for the intensity attribute in ReciprocalLatticeVector? If you're interested in the kinematical scattering intensity I = |F|^2, this can be calculated from F = calculate_structure_factor(). The new attribute lacks a docstring. To me, just looking at the new additions and tests, the attribute looks like a placeholder for any array you want, attached to the ReciprocalLatticeVector class.
Why cannot the new simulation classes be part of the current simulation module, diffsims.sims? Having two modules for diffraction simulations is confusing.

CSSFrancis · 2024-04-21T16:38:06Z

So, sorry about the hold-up, @CSSFrancis.

Couple of questions right away:

Could you explain the reason for the intensity attribute in ReciprocalLatticeVector? If you're interested in the kinematical scattering intensity I = |F|^2, this can be calculated from F = calculate_structure_factor(). The new attribute lacks a docstring. To me, just looking at the new additions and tests, the attribute looks like a placeholder for any array you want, attached to the ReciprocalLatticeVector class.

That's a good question; it's mostly that we really want to calculate things once and then not do it again, or it's going to really slow down the orientation mapping. We can add a function calculate_scattering_intensity to the DiffractionVectors class? I can refactor that. That data also contains information about the intersection of the vectors and the Ewald sphere. Maybe this should be a separate object but it needs to be stored somewhere.

Why cannot the new simulation classes be part of the current simulation module, diffsims.sims? Having two modules for diffraction simulations is confusing.

Shorting names is fairly un-pythonic. A 1-1 mapping of Signal1D -> Simulation1D and Signal2D --> Simulation2D makes more sense in the long term. I want to make this change long-term in diffsims and don't want to break the pyxem API when that happens. I'm open to suggestions.

hakonanes · 2024-04-21T17:05:22Z

we really want to calculate things once and then not do it again

I totally understand that. That's why e.g. the structure_factor attribute carries over when slicing ReciprocalLatticeVector already.

We can add a function calculate_scattering_intensity to the DiffractionVectors class?

Hm, where is this class? We have the calculate_structure_factor() method to calculate kinematical scattering intensities for ReciprocalLatticeVector. This has served us well in kikuchipy for calculating kinematical EBSD patterns. We should ideally have one way of doing things. Having attributes for the structure factor F, calculated from calculate_structure_factor(), and then for an intensity I = |F|^2, which may not be derived from F, is confusing (to me).

That data also contains information about the intersection of the vectors and the Ewald sphere. Maybe this should be a separate object but it needs to be stored somewhere.

But, the end result is ultimately structure factors? Or the intensities directly? And what is the current route for calculating these structure factors (steps and input parameters)? It may be best to include that route into the ReciprocalLatticeVector class.

I want to make this change long-term in diffsims and don't want to break the pyxem API when that happens. I'm open to suggestions.

This is fine, and something I agree with in general. Can I suggest to present this idea in an issue for a discussion, albeit a brief one?

CSSFrancis · 2024-04-21T21:44:58Z

I totally understand that. That's why e.g. the structure_factor attribute carries over when slicing ReciprocalLatticeVector already.

We can add a function calculate_scattering_intensity to the DiffractionVectors class?

Hm, where is this class? We have the calculate_structure_factor() method to calculate kinematical scattering intensities for ReciprocalLatticeVector. This has served us well in kikuchipy for calculating kinematical EBSD patterns. We should ideally have one way of doing things. Having attributes for the structure factor F, calculated from calculate_structure_factor(), and then for an intensity I = |F|^2, which may not be derived from F, is confusing (to me).

I misspoke sorry :) Trying to deal with too many things at one time... I meant ReciprocalLatticeVector (DiffractionVectors is a similar class in pyxem).

Maybe it's best if we think about the entire workflow and determine which parts should be methods for ReciprocalLatticeVector

We want to:

1 - Copy the ReciprocalLatticeVector class
2 - Rotate the ReciprocalLatticeVector (to do this I added the rotate_from_matrix function
3 - Determine which ReciprocalLatticeVector vectors intersect the Ewald Sphere
4 - Calculate the diffraction intensities. This includes the Debye Waller factors and the shape function.
5 - Remove ReciprocalLatticeVector vectors below a cutoff intensity

For step 4, we can derive the intensities from the structure factor. We just need to make sure we are only calculating this once; otherwise, it might slow down the template matching. We must also add Debye Waller factors and the shape function. Having these factors in the ReciprocalLatticeVector class is a bit weird as they are more closely related to the SimulationGenerator.

That data also contains information about the intersection of the vectors and the Ewald sphere. Maybe this should be a separate object but it needs to be stored somewhere.

But, the end result is ultimately structure factors? Or the intensities directly? And what is the current route for calculating these structure factors (steps and input parameters)? It may be best to include that route into the ReciprocalLatticeVector class.

See above. The result that we care about if the diffraction intensity for comparison. I don't think we want those steps in the ReciprocalLatticeVector as it requires that the ReciprocalLatticeVector object has information about the Ewald sphere which seems like it should be part of the SimulationGenerator. I could be convinced otherwise.

I guess the question is: If you wanted to plot the diffraction spots and the Kikuchi lines, how would that look/ how is that handled? It might be nice to do something like: s.plot(diffraction=True, kikuchi_lines=True)

I want to make this change long-term in diffsims and don't want to break the pyxem API when that happens. I'm open to suggestions.

This is fine, and something I agree with in general. Can I suggest to present this idea in an issue for a discussion, albeit a brief one?

Sounds good :)

hakonanes · 2024-04-22T19:47:24Z

I don't think we want those steps in the ReciprocalLatticeVector as it requires that the ReciprocalLatticeVector object has information about the Ewald sphere which seems like it should be part of the SimulationGenerator.

I agree! It sounds like we want the generator to use ReciprocalLatticeVector (composition), rather than adding to the vector class. I'm of the opinion that no microscope- or geometry-specific parameters should be part of this class.

The only method that takes a microscope parameter, an accelerating voltage, is calculate_theta() for populating the theta attribute, twice the Bragg angle. This should arguably not be an attribute of the class, because information of the voltage is lost upon return. And having a ReciprocalLatticeVector.voltage attribute makes no sense. But, it's been a part of the API for many years, so it should be kept.

We must also add Debye Waller factors

These are already part of the diffpy.structure atoms API in the Atom.Bisoequiv attribute. Can you use this? The factors are used when calculating the atomic scattering factors, f (used in ReciprocalLatticeVector.calculate_structure_factor()):

diffsims/diffsims/structure_factor/atomic_scattering_factor.py

Lines 62 to 64 in bb359b9

    
           # Correct for occupancy and the Debye-Waller factor 
        
           dw_factor = np.exp(-atom.Bisoequiv * s2) 
        
           f *= atom.occupancy * dw_factor

It might be nice to do something like: s.plot(diffraction=True, kikuchi_lines=True)

What is s here? What information about the microscope, phase, detector, and scattering vectors does it have?

We have plotting of Kikuchi lines in kikuchipy (see this tutorial). It may be that the simulation generator should be upstreamed to diffsims, but that would also require upstreaming EBSDDetector, which powers most of kikuchipy... Perhaps just taking necessary code from kikuchipy is fine for the Kikuchi lines. I don't know.

CSSFrancis · 2024-04-23T12:27:43Z

I agree! It sounds like we want the generator to use ReciprocalLatticeVector (composition), rather than adding to the vector class. I'm of the opinion that no microscope- or geometry-specific parameters should be part of this class.

The only method that takes a microscope parameter, an accelerating voltage, is calculate_theta() for populating the theta attribute, twice the Bragg angle. This should arguably not be an attribute of the class, because information of the voltage is lost upon return. And having a ReciprocalLatticeVector.voltage attribute makes no sense. But, it's been a part of the API for many years, so it should be kept.

@hakonanes Okay, so what do we do about the diffraction intensity, which depends on the microscope parameters? I can separate them if you like and make that an attribute of Simulation2D. Still, then there is always the possibility that you have more intensity values than ReciprocalLatticeVectors if someone slices either of them.

We must also add Debye Waller factors

These are already part of the diffpy.structure atoms API in the Atom.Bisoequiv attribute. Can you use this? The factors are used when calculating the atomic scattering factors, f (used in ReciprocalLatticeVector.calculate_structure_factor()):

diffsims/diffsims/structure_factor/atomic_scattering_factor.py

Lines 62 to 64 in bb359b9

# Correct for occupancy and the Debye-Waller factor

dw_factor = np.exp(-atom.Bisoequiv * s2)

f *= atom.occupancy * dw_factor

I'm not really trying to change everything all at once... Can we leave that to another PR? This PR is just supposed to use the orix phase class and ReciprocalLatticeVector so we should focus on making that one change and then clean up any other part that we feel isn't working. This PR is holding up a lot and we need to figure out how to get this in.

It might be nice to do something like: s.plot(diffraction=True, kikuchi_lines=True)

What is s here? What information about the microscope, phase, detector, and scattering vectors does it have?

That would be your Simulation2D object. It might make more sense to calculate the two separately and add them to the same plot. It might also be nice to have one SimulationGenerator object that can do both kikuchi and vector diffraction.

We have plotting of Kikuchi lines in kikuchipy (see this tutorial). It may be that the simulation generator should be upstreamed to diffsims, but that would also require upstreaming EBSDDetector, which powers most of kikuchipy... Perhaps just taking necessary code from kikuchipy is fine for the Kikuchi lines. I don't know.

For now maybe we can just have a tutorial that makes a combined plot is someone is interested.

CSSFrancis · 2024-04-23T14:03:36Z

@hakonanes I guess the question is what needs to be changed for this to be merged? Most of this is just copied from the old function. It's not really anything new, just makes it significantly faster and (somewhat) cleaner.

viljarjf · 2024-05-07T12:37:12Z

diffsims/simulations/simulation2d.py

+        theta_templates = np.zeros((len(flattened_vectors), max_num_spots))
+        intensities_templates = np.zeros((len(flattened_vectors), max_num_spots))
+        for i, v in enumerate(flattened_vectors):
+            r, t, _ = v.to_polar()


I am getting some strange results when I try to template match, and I believe this line is the cause. Should it not be t, _, r = v.to_polar()? Seeing as Vector3d.to_polar returns (azimuthal, polar, radius) spherical coordinates. By inspection, the current way yields t-values close to pi/2, which would make sense for the polar angle with a mostly flat Ewald's sphere.

@viljarjf Sorry, I've gotten kind of confused with all of these comments and changes. We don't want to use that function at all... We want the radius of the projection of the vector onto the x,y plane.

@viljarjf This (should) be better

hakonanes

I've had a look at the new changes.

hakonanes · 2024-05-07T19:12:04Z

diffsims/crystallography/_diffracting_vector.py

+    This extends the :class:`ReciprocalLatticeVector` class.  Diffracting Vectors
+    focus on the subset of reciporical lattice vectors that are relevant for


Suggested change

This extends the :class:`ReciprocalLatticeVector` class. Diffracting Vectors

focus on the subset of reciporical lattice vectors that are relevant for

This extends the :class:`ReciprocalLatticeVector` class. `DiffractingVector`

focus on the subset of reciprocal lattice vectors that are relevant for

hakonanes · 2024-05-07T19:13:02Z

diffsims/crystallography/_diffracting_vector.py

+    This class is only used internally to store the DiffractionVectors generated from the
+    DiffractionSimulation class. It is not (currently) intended to be used directly by the user.


Suggested change

This class is only used internally to store the DiffractionVectors generated from the

DiffractionSimulation class. It is not (currently) intended to be used directly by the user.

This class is only used internally to store the diffracting vectors generated from a

:class:`~diffsims.simulations.DiffractionSimulation`. It is not intended to be used

directly by the user.

diffsims/crystallography/_diffracting_vector.py

hakonanes · 2024-05-07T19:22:35Z

diffsims/crystallography/_diffracting_vector.py

+        self._intensity = np.array(value)
+
+    @property
+    def lattice_aligned_data(self):


So these vectors are the same as they were before rotated by a rotation. Can't we separately keep track of a set of starting vectors, a rotation, and a set of rotated vectors? Why do these separate things have to be stored in a single class instance?

Hmm.... I think this is related to above. What use is the RLV if it doesn't have information about the Rotation otherwise it is just the same as a Vector3D with confusing hkl values that don't really make physical sense and look correct because they are rounded.

hakonanes · 2024-05-07T19:28:36Z

diffsims/crystallography/_diffracting_vector.py

+
+    def to_flat_polar(self):
+        """Return the vectors in polar coordinates as projected onto the x,y plane"""
+        r = np.linalg.norm(self.data[:, :2], axis=1)


What if self.data.ndim > 2? The reciprocal lattice vectors, as normal 3D vectors, are allowed to have a "navigation shape" > 1. I suggest to flatten before extracting the x, y coordinates.

Good point.

hakonanes · 2024-05-07T19:29:16Z

diffsims/crystallography/reciprocal_lattice_vector.py

@@ -18,6 +18,7 @@

 from collections import defaultdict
 from copy import deepcopy
+from typing import Tuple


This line can be dropped.

hakonanes · 2024-05-07T19:32:34Z

diffsims/generators/simulation_generator.py

+from orix.quaternion import Rotation
+from orix.crystal_map import Phase
+
+from diffsims.crystallography import ReciprocalLatticeVector, DiffractingVector


Can the diffracting vector class be private?

You state in its docstring that it is not meant to be used by end-users. This tells me that the logic should be a simpler class or sets of functions to handle this particular use-case, instead of a public class with many caveats.

If the user wants the original reciprocal lattice vectors, rotations, or rotated vectors, can they instead get ReciprocalLatticeVector or Rotation (preferably the more powerful Orientation)?

diffsims/crystallography/reciprocal_lattice_vector.py

CSSFrancis · 2024-05-07T19:54:18Z

@hakonanes I think lots of the confusion is related to not properly handling the rotation with the RLV.

We need to track the rotations applied to the RLV to recover the hkl. This is possible with pyxem/orix#499 and adding the rotation property to the RLV.

from orix.crystal_map import Phase
from orix.quaternion import Rotation
from diffsims.crystallography import ReciprocalLatticeVector
import numpy as np

phase = Phase(point_group="m-3m")
g = ReciprocalLatticeVector(phase, [[1, 1, 1], [1,0,0]])

R1 = Rotation.random(2)
random1 = R1 * g
R2 = Rotation.random(2)
random2 =R2*random1

assert np.allclose(g.hkl, random1.hkl) # Previously this would fail
assert np.allclose(g.hkl, random2.hkl) # Previously this would fail

I can push this change if you want but it requires pyxem/orix#499.

I think this helps the logic quite a bit but does change the ReciprocalLatticeVector class a little bit.

setup.cfg

hakonanes · 2024-05-07T20:23:55Z

I'm just going to make the DiffractingVector class private

Perfect. Then I've got no objections to how that class is used internally in diffsims.

diffsims/crystallography/__init__.py

This reverts commit 05b3736.

CSSFrancis · 2024-05-08T16:50:49Z

@hakonanes I made some changes based on @viljarjf's suggestion in #211

viljarjf · 2024-05-08T17:05:21Z

diffsims/crystallography/reciprocal_lattice_vector.py

+            matrix = value
+        else:
+            raise ValueError("Rotation must be a Rotation or a 3x3 numpy array")
+        self.phase.structure.lattice.setLatPar(baserot=matrix)


Phases are passed by refrence, so this would affect all other vectors with the same phase.
This is why I copied the phase in rotate_with_basis.

Suggested change

self.phase.structure.lattice.setLatPar(baserot=matrix)

self.phase = self.phase.deepcopy()

self.phase.structure.lattice.setLatPar(baserot=matrix)

The base rotation is not always the identity as well, especially for hexagonal crystals from cif or initialized from a structure. This comes from the enforced x || a, z || c* convention used in orix (https://orix.readthedocs.io/en/stable/tutorials/crystal_reference_frame.html).
What do you intend the basis_rotation member to be used for?

Fair point. I'll probably just remove this then. I added it for completeness sake but didn't realize that the base rot was used for hexagonal phases.

CSSFrancis · 2024-05-08T21:20:47Z

Based on:

I just made everything part of the private DiffractingVectors class. That way, we can merge things and start working on the next part, the Simulation Part of this code is much more straight forward and I'm much more confident on that implementation.

@hakonanes can you take another pass through and then we can think about merging?

hakonanes

Just a few suggestions left. After those are addressed, I'm OK with the parts of this PR that I've reviewed. Will have a final look after that.

diffsims/crystallography/_diffracting_vector.py

diffsims/tests/crystallography/test_reciprocal_lattice_vector.py

CSSFrancis · 2024-05-09T13:35:25Z

Just a few suggestions left. After those are addressed, I'm OK with the parts of this PR that I've reviewed. Will have a final look after that.

Done!

CSSFrancis · 2024-05-09T15:30:04Z

@hakonanes Did you want to do another pass through or do you want to merge?

hakonanes · 2024-05-09T15:38:21Z

Fingers crossed the simulations work as you intended in the wild next week!

CSSFrancis · 2024-05-09T15:45:14Z

Fingers crossed the simulations work as you intended in the wild next week!

At the very least it's an improvement :) Thanks for your help here!

CSSFrancis added 7 commits April 17, 2024 08:11

New Feature: Add Simulation classes using Phase Class

1fc6a87

New Feature: Add intensity to reciprocal lattice vector

8282721

Testing: Add tests for adding intensity of reciprocal_lattive_vector.py

bfe0505

New Feature: Added zerobeam to reciprocal lattice vector

ac97ee6

New Feature: Moved Shape factor calculation to shape_factor_models.py

b0b67fa

Testing: Added testing for simulation_generator.

6ec15b8

Testing: Testing the zero Beam is most intense.

f3bd483

CSSFrancis force-pushed the use_phase_class2 branch from 6d884bb to f3bd483 Compare April 17, 2024 13:11

CSSFrancis added 4 commits April 17, 2024 08:24

Min Version: Bump orix min version

d7c86ec

Packaging: Include function and classes in init file

ef03b39

Testing: Clean up tests due to changed function name

d1839a5

Testing: Add coverage for simulation classes

3567308

CSSFrancis requested review from hakonanes and pc494 April 17, 2024 14:19

Documentation: Fixed Broken documentation

66f0133

CSSFrancis mentioned this pull request Apr 17, 2024

Add Documentation Examples #209

Merged

7 tasks

viljarjf reviewed Apr 21, 2024

View reviewed changes

Refactor: Fixes per @viljarjf

3d9c662

viljarjf approved these changes Apr 21, 2024

View reviewed changes

viljarjf reviewed May 7, 2024

View reviewed changes

Bugfix: Fix polar conversion

c39e357

hakonanes requested changes May 7, 2024

View reviewed changes

hakonanes mentioned this pull request May 7, 2024

Exclude test suite from source distribution #212

Closed

hakonanes reviewed May 7, 2024

View reviewed changes

setup.cfg Show resolved Hide resolved

hakonanes mentioned this pull request May 7, 2024

Rotation of ReciprocalLatticeVector throws an error #211

Open

hakonanes reviewed May 7, 2024

View reviewed changes

diffsims/crystallography/__init__.py Outdated Show resolved Hide resolved

Bugfix: Fix Rotation with RLV

05b3736

CSSFrancis mentioned this pull request May 8, 2024

Refactor orientation mapping3 viljarjf/pyxem#1

Merged

CSSFrancis added 2 commits May 8, 2024 10:38

Revert "Bugfix: Fix Rotation with RLV"

bfbd299

This reverts commit 05b3736.

Testing: Improve testing

96a48ec

viljarjf reviewed May 8, 2024

View reviewed changes

CSSFrancis added 3 commits May 8, 2024 12:56

Refactor: Improve based on @hakonanes and @viljarjf's suggestions

1f2150d

Refactor: Tests including zero-vector

efde31d

Refactor: Remove changes from RLV

da45a32

hakonanes requested changes May 9, 2024

View reviewed changes

diffsims/crystallography/_diffracting_vector.py Show resolved Hide resolved

diffsims/tests/crystallography/test_reciprocal_lattice_vector.py Outdated Show resolved Hide resolved

diffsims/tests/crystallography/test_reciprocal_lattice_vector.py Outdated Show resolved Hide resolved

Refactor: suggestions for @hakonanes

0e97f22

hakonanes approved these changes May 9, 2024

View reviewed changes

CSSFrancis mentioned this pull request May 9, 2024

0.6.0 Release #200

Closed

16 tasks

hakonanes merged commit 507dda2 into pyxem:main May 9, 2024
11 checks passed

This was referenced May 9, 2024

Redesign of Simulations #198

Closed

Rewriting Libraries (structure and diffraction) #135

Closed

	"""Returns the matrix for the current matrix"""
	"""Returns the matrix for the current rotation"""

		This extends the :class:`ReciprocalLatticeVector` class. Diffracting Vectors
		focus on the subset of reciporical lattice vectors that are relevant for

		This class is only used internally to store the DiffractionVectors generated from the
		DiffractionSimulation class. It is not (currently) intended to be used directly by the user.

	self.phase.structure.lattice.setLatPar(baserot=matrix)
	self.phase = self.phase.deepcopy()
	self.phase.structure.lattice.setLatPar(baserot=matrix)

Use phase class2 #205

Use phase class2 #205

Conversation

CSSFrancis commented Apr 12, 2024 • edited Loading

Description of the change

Progress of the PR

Minimal example of the bug fix or new feature

For reviewers

CSSFrancis commented Apr 20, 2024

viljarjf left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CSSFrancis commented Apr 21, 2024 • edited Loading

viljarjf left a comment

Choose a reason for hiding this comment

hakonanes commented Apr 21, 2024

hakonanes commented Apr 21, 2024

hakonanes commented Apr 21, 2024

CSSFrancis commented Apr 21, 2024 • edited Loading

hakonanes commented Apr 21, 2024

CSSFrancis commented Apr 21, 2024 • edited Loading

hakonanes commented Apr 22, 2024

CSSFrancis commented Apr 23, 2024

CSSFrancis commented Apr 23, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hakonanes left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CSSFrancis commented May 7, 2024 • edited Loading

hakonanes commented May 7, 2024

CSSFrancis commented May 8, 2024

viljarjf May 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CSSFrancis commented May 8, 2024

hakonanes left a comment

Choose a reason for hiding this comment

CSSFrancis commented May 9, 2024

CSSFrancis commented May 9, 2024

hakonanes commented May 9, 2024 • edited Loading

CSSFrancis commented May 9, 2024

CSSFrancis commented Apr 12, 2024 •

edited

Loading

CSSFrancis commented Apr 21, 2024 •

edited

Loading

CSSFrancis commented Apr 21, 2024 •

edited

Loading

CSSFrancis commented Apr 21, 2024 •

edited

Loading

CSSFrancis commented May 7, 2024 •

edited

Loading

viljarjf May 8, 2024 •

edited

Loading

hakonanes commented May 9, 2024 •

edited

Loading