Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/topcharge #265

Merged
merged 11 commits into from
Jul 2, 2020
Merged

Feature/topcharge #265

merged 11 commits into from
Jul 2, 2020

Conversation

JeroenMulkers
Copy link
Collaborator

This is an alternative for the topologicalchargelattice implementation proposed in pull request #262.

The local topological charge is computed by taking a weighted sum of the topological charge contributions of the four elementary triangles defined by the four nearest neighbours.

In general, the elementary triangles of neighbouring cells overlap, in which case the charge contributions are counted twice. This is solved by using a weight of 1/2. (Exactly the same is done in the topologicalchargelattice implementation in #262)

However, the triangle at a convex corner of the geometry does not overlap any other triangles. Hence, at convex corners we use a weight of 1.

nov2oj and others added 10 commits July 2, 2020 10:51
Provides "ext_topologicalchargelattice" extension that computes the topological charge using a lattice-based formalism, rather than the discretisation of the continuum form.
Re-introduced cell volumes to obtain true density for the topological charge. Comparable to output from ext_topologicalcharge
Convex corners are now treaded correctly in topologicalchargelattice.
topologicalchargefinitelattice is now redundant, and hence removed.
@JeroenMulkers JeroenMulkers merged commit f5ed7e1 into master Jul 2, 2020
@godsic
Copy link
Contributor

godsic commented Jul 2, 2020

@JeroenMulkers How does it score accuracy-wise in tests?

@JeroenMulkers
Copy link
Collaborator Author

It gives exactly the same results as Joo-Von's implementation in the unit tests. These unit tests have a trivial geometry, in which case both implementations are equivalent, and hence we expect that it yields the same results

The only thing which is different here, is that the contribution of a triangle is counted twice in a convex corner of the geometry.

@godsic
Copy link
Contributor

godsic commented Jul 2, 2020

@JeroenMulkers Good. Please give credit to the Joo-Von in the sources and make sure we ask to cite his paper if feature is used.

@JeroenMulkers JeroenMulkers deleted the feature/topcharge branch August 5, 2020 12:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants