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

Create unit tests for PCISPH demos to verify non-violation of classical physics laws. #86

Closed
slarson opened this issue Apr 19, 2013 · 8 comments

Comments

@slarson
Copy link
Member

slarson commented Apr 19, 2013

Mentioned as a need in the context of the discovery of the conservation of momentum violation bug #84

@slarson
Copy link
Member Author

slarson commented May 18, 2013

Is anyone working on this? Who will step up and assign themselves?

@a-palyanov
Copy link
Member

Current status is the following: My computational experiments showed that if I turn off all liquid-related interations (and leave only mass-spring interaction forces) there is no any violation of physical laws, even when contraction of piece of elastic matter is quite significant (large contraction forces). I have not observed even a single case of violation trying many conditions. This revealed that liquid-related interactions are responsible for violation (well, this shouldn't be a surprise - it is known that PCISPH is quite a high-quality algorithm, but it has inherent precision limits and is not completely physically-correct). But in most cases it is still very realistic (and enough for all our purposes). Violation happens only in case when elastic matter piece contracts too much (big contraction force value), but in fact we don't need to work with such force values. I've empirically found threshold value, quite enough for biological muscles, which causes not violation. So I'd offer to consider that this problem is fixed, because we now understand its origin and limits of application.

@slarson
Copy link
Member Author

slarson commented May 21, 2013

The idea of having tests though is to make sure that issues like this don't come back if the code changes in the future. From a perspective of software maintenance, this could be very important. Should we reconsider not creating these tests? @tarelli and @JohnIdol can you weigh in?

@slarson slarson reopened this May 21, 2013
@gidili
Copy link
Member

gidili commented May 21, 2013

Well yes - it would be great to have a battery of tests that between other things ensure non violation of classic physics laws (at least the ones we are interested in). It would become orders of magnitude easier to work on the ported (Java) version once we have such tests - since at the moment there is no criteria (other than visual) to determine if the 2 version effectively do the same thing.

@a-palyanov
Copy link
Member

Sorry for closing this issue, at that moment I thought it was only about conservation of momentum violation bug. Sure I agree that unit tests verifying non-violation of classical physics laws are essential. I think that me or Sergey (or both) will surely participate in this.

@slarson slarson closed this as completed Mar 5, 2014
@vellamike
Copy link
Contributor

Has this definitely been done? Is there a link to the tests?

On 5 March 2014 05:54, Stephen Larson notifications@github.com wrote:

Closed #86 #86.

Reply to this email directly or view it on GitHubhttps://github.com//issues/86
.

@Neurophile
Copy link

As far as I know @a-palyanov is still active on this. Just a few days ago he reported on experiments testing if various numerical integration methods obeyed basic mass+spring physics.

@slarson
Copy link
Member Author

slarson commented Mar 5, 2014

Issue hasn't been updated in 10 months, isn't assigned to anyone, and as currently described is very open ended and unclear when it would be completed (since the conservation of momentum issue). If we want these tests, let's come up with a more narrowly worded issue and let's make it clear who is in charge of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants