search

ACEsuit / ACE.jl

Parameterisation of Equivariant Properties of Particle Systems
65 stars 15 forks source link

Unification of Generalized CoCos #28

Closed cortner closed 3 years ago

cortner commented 3 years ago

Attempt to unify general coupling coefficients (cocos).

CC @MatthiasSachs @zhanglw0521 If you make changes to this branch, please just push to my fork and the PR will be automatically updated.

cortner commented 3 years ago

sorry I didn't manage to finish the first steps tonight but I'm too tired now. Please feel free to continue from where I left off, but I'll try to continue immediately after school dropoff.

cortner commented 3 years ago

Invariants are now working ok - @zhanglw0521 and @MatthiasSachs this is ready for you to start incorporating your versions. However, I still need to move some codes from rotations to symmbasis so I fear there will still be some failures.

EDIT: I think I've sorted that out now. Only thing missing is admitting multiple initial conditions.

cortner commented 3 years ago

Invariant and EuclideanVector work in the rewrite. You turn @zhanglw0521 :)

cortner commented 3 years ago

@MatthiasSachs @zhanglw0521 I think we have implemented everything we want, and all tests pass now.

  1. Are you happy to merge?
  2. How do you feel about tagging a first release?
MatthiasSachs commented 3 years ago

stupid question: "tagging" would mean we give ACE a new version number after merging the coco branch into main?

cortner commented 3 years ago

yes but a new v0.x.y tag which means we don't yet enforce backward compatibility. Specifically my proposal is

zhanglw0521 commented 3 years ago

The main conflict with ACE1 is that we now need to specify the property even when we use the invariant basis only? Do we need to fix the incompatibility in the future or do we just consider ACE1 and ACE2 as separate things?

cortner commented 3 years ago

ACE2 is so different, there is no compatibility left I think.

But for practical purposes: we follow semver. (semantic versioning) This means that we may break compatibility if we go from v0.x.* to v0.(x+1).* and if we go from vX.* to v(X+1).*. Further, for vX.y.z the z stands for patches and bug fixes while y stands for new features.

cortner commented 3 years ago

let's put the versiom discussion elsewhere and focus on merging. I see you are both happy so I'll go ahead with that.