Astner
Granted this isn't the most active forum and there aren't that many calculations in total, most of them being made and posted in long threads. However I'd like to post a few guidelines to make it easier on the ones that read as well as on yourself.
Write down all assumptions
Including everything from constant acceleration to the length of an object or character. Present the assumptions directly and don't hide them as if they would be weaknesses.
In order for people (including yourself) to fully understand the calculation it's essential to understand every step of it. It becomes a lot easier to follow the calculation when you know what assumptions that are being made.
Granted you don't have to write down every little detail, like the planet's movement during the process--as long as that wouldn't affect the nature of the event relevantly--but pretty much all the basic assumptions that are actually used are expected to be written down.
Motivate your assumptions
A reasonable motivation would be: "We assume that the acceleration is constant over the distance in order to get a low-end estimation for the speed."
This because the Achilles' heal of every calculation is the assumptions that are being made. If certain assumptions happen to be inaccurate for whatever reason the entire calculation could fall, depending on it's feedback.
Write down the given values used, and provide evidence
Whether it's a value for density distribution parameter or a Physical constant, and provide a reference or a link so that people can confirm these values for themselves.
In case you were to use a odd unit or measurement which you've converted incorrectly it's always easier to spot them this way.
If it's an algebraic calculation, post all of it
There's no reason not to.
Algebraic calculations are rather easy to write down and easy to correct in case of an error.
If it's an numeric calculation, explain it
Since not all problems can be solved algebraically sometimes it's best to approach the problem through mathematical programming. Especially when dealing with details and non-linearity. In case of MATLAB or any other numeric software, there can be plenty of code scattered around in over a dozen of files with code--even when known--can be messy and confusing.
An explanation of how the program is built will most likely tell you more of the purpose of the program than the code will.
If it's a graphical calculation, explain it
In case of LS-DYNA or any other graphical software, it's important that you explain what you've actually done. Everything from why you choose to approach the problem graphically to what boundary conditions you've chosen. Also provide a ton of pictures, it is after all graphical.
There's not that much that can be said, since the versatility of graphical programming is generally more restricted than numerical programming as you're not able to work outside of the box. But provide as much information as you can and be prepared to answer questions.
Don't be afraid to admit to mistakes and ask questions
If something turns out to be wrong, post and explanation why and if you're insecure ask questions regarding the methods you've used. There's no reason to have an inaccurate calculation floating around and confusing member.
Write down all assumptions
Including everything from constant acceleration to the length of an object or character. Present the assumptions directly and don't hide them as if they would be weaknesses.
In order for people (including yourself) to fully understand the calculation it's essential to understand every step of it. It becomes a lot easier to follow the calculation when you know what assumptions that are being made.
Granted you don't have to write down every little detail, like the planet's movement during the process--as long as that wouldn't affect the nature of the event relevantly--but pretty much all the basic assumptions that are actually used are expected to be written down.
Motivate your assumptions
A reasonable motivation would be: "We assume that the acceleration is constant over the distance in order to get a low-end estimation for the speed."
This because the Achilles' heal of every calculation is the assumptions that are being made. If certain assumptions happen to be inaccurate for whatever reason the entire calculation could fall, depending on it's feedback.
Write down the given values used, and provide evidence
Whether it's a value for density distribution parameter or a Physical constant, and provide a reference or a link so that people can confirm these values for themselves.
In case you were to use a odd unit or measurement which you've converted incorrectly it's always easier to spot them this way.
If it's an algebraic calculation, post all of it
There's no reason not to.
Algebraic calculations are rather easy to write down and easy to correct in case of an error.
If it's an numeric calculation, explain it
Since not all problems can be solved algebraically sometimes it's best to approach the problem through mathematical programming. Especially when dealing with details and non-linearity. In case of MATLAB or any other numeric software, there can be plenty of code scattered around in over a dozen of files with code--even when known--can be messy and confusing.
An explanation of how the program is built will most likely tell you more of the purpose of the program than the code will.
If it's a graphical calculation, explain it
In case of LS-DYNA or any other graphical software, it's important that you explain what you've actually done. Everything from why you choose to approach the problem graphically to what boundary conditions you've chosen. Also provide a ton of pictures, it is after all graphical.
There's not that much that can be said, since the versatility of graphical programming is generally more restricted than numerical programming as you're not able to work outside of the box. But provide as much information as you can and be prepared to answer questions.
Don't be afraid to admit to mistakes and ask questions
If something turns out to be wrong, post and explanation why and if you're insecure ask questions regarding the methods you've used. There's no reason to have an inaccurate calculation floating around and confusing member.