Explicit operation order determined by user definition

[skim0119]

Explicit operation order

• User-API would remain the same

Description

Previous implementation has ambiguity in determining the order of operation for different boundary conditions: forcing, contact, friction, connection, etc. For example, contact and friction must be calculated after all other boundary conditions are in place, and strictly contact must be computed before friction since friction depends on contact. In various place in the code, we tried to rearange the order without explicitly letting user know:

PyElastica/elastica/modules/base_system.py

Lines 173 to 182 in 87a2e74

	_call_contacts_index = []
	for idx, feature in enumerate(self._feature_group_synchronize):
	if feature.__name__ == "_call_contacts":
	_call_contacts_index.append(idx)
	# Move to the _call_contacts to the end of the _feature_group_synchronize list.
	for index in _call_contacts_index:
	self._feature_group_synchronize.append(
	self._feature_group_synchronize.pop(index)
	)

,

PyElastica/elastica/modules/forcing.py

Lines 72 to 81 in 87a2e74

	# Find if there are any friction plane forcing, if add them to the end of the list,
	# since friction planes uses external forces.
	friction_plane_index = []
	for idx, ext_force_torque in enumerate(self._ext_forces_torques):
	if isinstance(ext_force_torque[1], AnisotropicFrictionalPlane):
	friction_plane_index.append(idx)
	# Move to the friction forces to the end of the external force and torques list.
	for index in friction_plane_index:
	self._ext_forces_torques.append(self._ext_forces_torques.pop(index))

.
This cause ambiguity on user, especially when user wants to define their own boundary condition.

Solution

As long as we let users to write their own boundary conditions, we cannot anticipate every possible cases of operation dependencies. We are shifting to the policy that user must be aware of the boundary operation order.

This PR removes any "back-end" sorting the operation order. Operation order is now strictly defined by the order of user inserting any boundary condition with .using. This applies to forcing, contact, and connection as of now.

Some remaining TODOs:

• Add warning messages on packaged contact and friction modules
• Refactor synchronize operations: "first-in" boundary condition computes first
• Test
  • Fix existing tests
  • Implement new test for testing operation order
• Documentation (f0fc544)

[armantekinalp]

I have some questions. But overall looks good.

[armantekinalp]

LGTM