[WIP][1.8.1, 1.9.1, 1.10.1, 1.11.0–2, 1.12.2–5] Principia—version ‎‎Kronecker, released 2024-11-01—n-Body and Extended Body Gravitation

[hypervelocity]

13 hours ago, Kobymaru said:

So I have been trying to use the flight planner of Principia, and I have to say... it's a bit of a mess.

It is a bit, yes - but consider the game-changing experience the mod is providing. I think we can live with the messy flight plan as it is.

Quote

• After a maneuver has been executed, the flight plan is null and void, because the real trajectory and the flight plan will never match up. That means, you have to
  • Delete all maneuvers except the first, one by one by one
  • Delete the flight plan
  • Create the flight plan
  • Recreate all maneuvers,  one by one by one

I find this to be the most annoying part of it - but hey, what can you do! Just put your best face and get it done!

Quote

I'm kind of curious how people actually execute maneuvers, and whether I am the only one with RemoteTech.

I execute my manoeuvres with Remote Tech's flight computer. I first plot my flight plan and select 'Show on Navball" to obtain the manoeuvre node direction. Once that's done, I check the remaining time to ignition & the intended delta-v to be expended. With this data, I set up a BURN order in Remote Tech's flight computer - I first set the command's delay (if manoeuvre node is at T minus 1 hour, that's what I set it to in the flight computer), then request the computer to burn XXX m/s (as indicated by Principia's flight plan), and set it at 100% throttle. Once the order has been sent to the computer, I point the ship to the manoeuvre node.

Finally, once the engines start, I make sure to turn on SAS / SmartA.S.S. and hold the current attitude. I know the manoeuvre node will change position sometime during the middle of the burn, but I don't care. I just keep burning in the original direction, and that gets me to execute my flight plans quite acceptably, with little deviation. As you have set the engines to expend a determined amount of delta-v, you don't need to worry about engine shutdown as it will happen automatically, without having to worry about the Remote Tech / Principia clock discrepancy (which I have not noticed in my game - not saying it's not there though, I have not looked carefully).

Hope this helps!

EDIT: repeating stuff already said by @lawndart, sorry - didn't see that post!

Edited January 23, 2018 by hypervelocity

[Kobymaru]

On 23.1.2018 at 9:00 AM, scimas said:

That's how you get more efficient burns (stock burns are directed at a constant direction. Which is why your orbit gets bigger and bigger when doing inclination change, you aren't burning normal to your trajectory at all times, you are burning along normal to the trajectory at the start of the burn).

OK, I get that. Still, why does the Node have to jump 90° when Principia thinks I'm done burning? That's just mean, honestly. 

On 23.1.2018 at 9:00 AM, scimas said:

There is a Time to engine cutoff readout in the flight planner, no need of a stop watch.

Thanks, that helps a bit.

On 23.1.2018 at 9:00 AM, scimas said:

And if you prefer the stock like burns, there's the option to have inertially fixed burns. Which I think should give you a stock ticking down node.

Just tried it and it doesn't tick down, it keeps getting overwritten.

On 23.1.2018 at 9:00 AM, scimas said:

I am using RemoteTech in one my saves right now, but I don't use its flight computer. Unless I want extremely precise manoeuvres that would require manually changing thrust limits, I use a kOS script to execute my burns.

I briefly considered kOS, but KSP is still a hobby and not my dayjob. I really don't want to start a whole software development project for each lander, and if RO supported it, I'd use the Stock Antenna system and role-played that I'm a Probe computer myself.

 

On 23.1.2018 at 9:00 AM, scimas said:

Don't know about RT, but I have noticed kOS getting out of sync with the game clock for as much as 5 - 10 seconds when time warping. But it corrects the error almost immediately.

Several hours over a 10-day period. I'll have to see what the in-game clock says, but what's for sure is that they are not agreeing.

 

On 23.1.2018 at 9:02 AM, lawndart said:

I use RemoteTech's flight computer to conduct burns. I usually put the required delta-V in the Burn duration field, set the throttle to 100%, use the Node button to set the attitude and smack the Burn button when the node countdown hits zero. If you use Kerbal Engineer Redux and have the time to node showing you can close the Principia windows and initiate the burn using that. This also restores the stock deltaV countdown.  

Thanks for the trick, I'll try that.

On 23.1.2018 at 9:02 AM, lawndart said:

Possibly some of the time calculation issues are down to my game requiring a whopping 36Gb of memory and I only have 16Gb RAM installed.

Whoopsie, really? I've been wondering why my 8 GB system starts swapping after half an hour of play, but that would explain it.

I doubt that the time difference is because of the memory, though. Feels more like principia does it's own time integration and doesn't synchronize it to the KSP clock.

 

On 23.1.2018 at 2:23 PM, hypervelocity said:

It is a bit, yes - but consider the game-changing experience the mod is providing. I think we can live with the messy flight plan as it is.

I do, and I still think the mod is amazing. I just think that it makes things harder than it has to.

 

On 23.1.2018 at 2:23 PM, hypervelocity said:

Finally, once the engines start, I make sure to turn on SAS / SmartA.S.S. and hold the current attitude. I know the manoeuvre node will change position sometime during the middle of the burn, but I don't care.

Why does it do that, though? Did somebody create a GitHub issue yet or have the devs mentioned anything about it?

[scimas]

15 minutes ago, Kobymaru said:

OK, I get that. Still, why does the Node have to jump 90° when Principia thinks I'm done burning? That's just mean, honestly.

I didn't comment on that because frankly I've never encountered this issue, the node gets deleted immediately after Time to cutoff reaches zero.. unless you're talking about the case where you have more than one manoeuvres in the plan. Then it immediately switches to the next manoeuvre, that might be your problem.

[Kobymaru]

11 hours ago, scimas said:

I didn't comment on that because frankly I've never encountered this issue,

I have, 3 times now.

11 hours ago, scimas said:

the node gets deleted immediately after Time to cutoff reaches zero.

OK, but why?

11 hours ago, scimas said:

 unless you're talking about the case where you have more than one manoeuvres in the plan. Then it immediately switches to the next manoeuvre, that might be your problem.

Nope, just the one node in there.

[awang]

On 1/22/2018 at 8:41 PM, Kobymaru said:

So I have been trying to use the flight planner of Principia, and I have to say... it's a bit of a mess. It's especially hard to get it to work with RemoteTech, which is kind of a "must" for a realist experience with Realism Overhaul.

The reason why Maneuver Nodes exist in KSP in the first place is not only for flight planning, but also as an Aid for Maneuver execution.

Now Principia cripples this aid, and seemingly for no reason:

This is more or less intentional; from what I understand, Principia's flight planner is explicitly *not* intended to help you execute your burn. This isn't because the devs hate players; from what I understand it's more that stock systems are insufficient for dealing with n-body physics, and there just hasn't been enough time to implement functionality that does work with n-body physics.

 

On 1/22/2018 at 8:41 PM, Kobymaru said:

• Maneuver nodes disappear after the burn time is supposedly over. That wouldn't be too bad, except RemoteTech and Principia don't seem to agree on the passage of time (Did you happen to implement relativity? ) and over the course of a few days, the RemoteTech clock is a few minutes behind, starts the burn too late and then tries to chase a maneuver node that doesn't exist anymore. Why does this have to be deleted? Wouldn't it be better to just leave the maneuver node there?

I've never run into anything like this, to be honest, so I can't really comment on it.

 

On 1/22/2018 at 8:41 PM, Kobymaru said:

• It seems that when checking "Show on Navball", Principia is constantly trying to overwrite the Maneuver Node. This seems like an OK idea until you actually try to do a Burn with it: first, you have no idea how much error you made and where to point the ship to correct it. Second, the timer and the Delta-V countdown is constantly stuck at the initial position. So how am I supposed to know when the burn is over? Do I have to use a stop watch?

Other people already addressed how Principia indicates burn duration, so I won't comment on that.

The overwriting and stuck timer/delta-v countdown parts are intentional, since the guidance corrections and timer/delta-v countdown that stock shows are only correct if you assume instantaneous burns. Principia's flight planner takes burn duration into account when calculating maneuver trajectories, so the numbers shown by KSP would be wrong. I believe it's technically possible for Principia to re-implement the functionality to get a correct time/delta-v countdown, as well as guidance corrections, but it's quite complex/time-consuming, so it hasn't been done yet.

 

On 1/22/2018 at 8:41 PM, Kobymaru said:

• After a maneuver has been executed, the flight plan is null and void, because the real trajectory and the flight plan will never match up. That means, you have to
  • Delete all maneuvers except the first, one by one by one
  • Delete the flight plan
  • Create the flight plan
  • Recreate all maneuvers,  one by one by one

As you can see, this is is not particularly user-friendly. Couldn't there be a button with "refresh flight plan" or something like it?
And maybe a readout that the flight plan is "stale"? Because it happened 3 times to me already that I executed a maneuver that was based on a stale flight plan accidentally, and ended up in a pretty useless Orbit.

Isn't stock also affected by something similar to this? If you have multiple maneuver nodes lined up, and the execution of the first one isn't totally accurate, you're going to have to go back and tweak/recreate the remaining nodes to get a proper update to your trajectory (or at least that's what I remember from the last time I used stock maneuver nodes).

 

On 1/22/2018 at 8:41 PM, Kobymaru said:

• In the middle of the burn, about when my eccentricity went above zero, the maneuver node jumped to a different location, wrecking my burn. I checked both the Maneuver frame and the Plotting Frame, and both were on "non-rotating fixing center of the earth", with the Navball displaying ECI

 

I'm kind of curious how people actually execute maneuvers, and whether I am the only one with RemoteTech.

I understand that many things with Principia change and therefor not all concepts of the Stock game apply. But it just seems that Principia makes it unnecessarily difficult. For example, I absolutely don't understand the fight with maneuver nodes. Here, the Stock game has simple, intuitive concepts that could be wonderfully put to use in Principia. Why doesn't it?

I think it's more a matter of there not having been enough time to implement functionality equivalent to stock, due to n-body physics making equivalent functionality much more difficult/complex to implement. Consider the amount of effort required to calculate orbital trajectories with KSP's physics model (relatively simple closed-form equations) vs real life n-body physics (have to use numerical integration). Now extend that to every other part of flight planning/maneuver execution.

 

On 1/22/2018 at 8:41 PM, Kobymaru said:

Instead of "Show on Navball", why can't there be a button that simply places a maneuver node exactly at the right time with the right burn vector?

Well, "Show on Navball" sort of does that, by showing the right burn vector with a countdown to the right time... As for not using maneuver nodes, it's because stock maneuver nodes (or at least what you'd expect from them) don't work too well with n-body physics.

 

On 1/22/2018 at 8:41 PM, Kobymaru said:

Then users could very easily execute the burn either manually (stock-style) or by slaving known tools such as the RemoteTech flight compuer or MechJeb to the maneuver node.

MechJeb at least partially works with Principia (or at least has in the past for me), since it reads the maneuver direction from the navball. You'll still have to start/stop the engines at the right time, though, since I don't believe any current mods expect nodes to take burn time into account.

[Jim DiGriz]

I just patched the PEG node executor in my development branch to handle Principia maneuver nodes.  So if you click "show on navball" then you get a maneuver node, and the PEG code will grab the osculating orbit on the other side of the maneuver node and use that as a target.  It then burns down until it hits the orbit (it doesn't use the maneuver node so doesn't care that the maneuver node itself doesn't burn down).  Of course if you use it for very long burns or low energy stuff when N-body physics is going to make the osculating orbit prediction over the course of the burn poor compared to the real N-body trajectory then that would void the warranty.

The problem right now though looks like Principia's flight planner has some bugs, because when I execute the node and burn it down accurately (within a 3-4 dV on a 1073dV planned burn) i wind up nowhere near the flight planner predictions (i have to crank the flight planner up to 1356 dV to get an orbit that somewhat matches the orbit that i wound up in and the shape of the planned orbit looks off if I do that (and MJ reports i burned 1077dV).

I don't have a release of that code since I just patched it an hour or two ago (and I did 2 releases yesterday so I'm feeling the release fatigue right now), but it'll go into the next release.

[scimas]

8 hours ago, Jim DiGriz said:

The problem right now though looks like Principia's flight planner has some bugs, because when I execute the node and burn it down accurately (within a 3-4 dV on a 1073dV planned burn) i wind up nowhere near the flight planner predictions

Never encountered this bug. I'm using a kOS script to execute nodes and the I'm tracking dV is simply summing (engine thrust * delta time) over the loop. And the prediction matches pretty well, I throttle down in the last second of the node to get burns within 0.02 m/s though.

[hypervelocity]

Quick one to all Principia aficionados here!

I would like to get better at flight planning. I have acquired my minimal knowledge by playing RO & RSS, and I determine my trajectories by using the Transfer Window Planner mod. I then proceed to eyeball the trajectory and try to plot it using the Flight Plan.

However, I would like to obtain basic orbital mechanics theorical knowledge to understand what type of orbits and transfers can be achieved, what are the various energy requeriments for these, how to imagine & execute gravity assists, be able to use Lagrangian points, and all those perks associated to the basic understanding of this science.

Hence my question: what would be the one piece of literature or internet resource that you would recommend to a beginner like me to achieve the aforementioned?

Many thanks in advance!

PS: maybe this question belongs to the Science subforum, but I take it most Principa users must be at least acquainted with the knowledge I am trying to obtain.

Edited January 29, 2018 by hypervelocity

[Jim DiGriz]

Looks like the trick I was missing was to turn off Principia's finite burn modelling, although I seem to have some kind of bug which shuts off the engines halfway through the burn, so I need to do some debugging before I can release a version which I can state truly handles burn execution with Principia.  I'm reasonably confident that I can work it out at this point though.

[scimas]

12 hours ago, hypervelocity said:

I determine my trajectories by using the Transfer Window Planner mod

Don't expect that mod to work very well with principia. It calculates everything assuming stock mechanics, but N-body gravitation perturbs things enough that the window AND transfer time both can change by several days.

12 hours ago, hypervelocity said:

I would like to obtain basic orbital mechanics theorical knowledge

Read up central force problem and two body problem in any classical mechanics textbook or even wikipedia.

[hypervelocity]

thanks @scimas!!! 

4 hours ago, scimas said:

Don't expect that mod to work very well with principia. It calculates everything assuming stock mechanics, but N-body gravitation perturbs things enough that the window AND transfer time both can change by several days.

I have indeed noticed this - I am only using Transfer Window Planner as an aproximation tool. That gives me a ballpark window & trajectory, which I then tweak manually to obtain the "best" transfer window & flight path.

[Jim DiGriz]

Interplanetary transfer planning generally starts with patched conic solutions.  Searching NTRS for "patched conics" turns up a bunch of references:

https://ntrs.nasa.gov/?N=0&Ntk=All&Ntt=patched conic&Ntx=mode matchallpartial&Nm=123|Collection|NASA STI||17|Collection|NACA

Where you wind up eventually is somewhere like this:

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20160001644.pdf

The patched conics stuff is fairly difficult undergraduate-level math.  The real stuff with n-body physics and proper optimization methods is going to be graduate level math (starting with Calculus of Variations and Primer Vector theory and then choosing some suitable optimization method to learn about).

Richard Battin's book is very good as a foundational reference (it won't present pre-packaged solutions to all these problems, but its essential background knowledge):

https://arc.aiaa.org/doi/book/10.2514/4.861543

He's pretty much the guy who did the math that sent the Apollo missions to the Moon (and invented all the math that went into late-50s and 60s-era IRBM/ICBM guidance).  There's some discussion in there on alternative means of doing trajectory optimization that only rely on undergrad-level calc, but they're involved.  Battin also has numerous tricks and insights.  That books is also probably the best reference on the Lambert problem that I've found.

Vallado's book is also good:

https://www.amazon.com/Fundamentals-Astrodynamics-Applications-Technology-Library/dp/1881883183

A better place to start out initially is probably:

https://www.amazon.com/Orbital-Mechanics-Engineering-Students-Aerospace/dp/0080977472

Note that if you're end goal is N-body interplanetary trajectory optimization, none of those books will really fully lay out a solution for you.

A graduate level textbook that gets you going with primer vector theory and introduction to TPBVP solvers is:

https://www.amazon.com/Optimal-Control-Aerospace-Applications-Technology/dp/146148944X

Then the book which actually talks about ways to solve the problem you really want to solve is:

https://www.amazon.com/Spacecraft-Trajectory-Optimization-Cambridge-Aerospace/dp/1107653827

 

Edited January 30, 2018 by Jim DiGriz

[eggrobin]

21 hours ago, Jim DiGriz said:

Looks like the trick I was missing was to turn off Principia's finite burn modelling, although I seem to have some kind of bug which shuts off the engines halfway through the burn, so I need to do some debugging before I can release a version which I can state truly handles burn execution with Principia.  I'm reasonably confident that I can work it out at this point though.

Summarizing some discussion on IRC, the issue is that @Jim DiGriz needs the trajectory after the manoeuvre, which Principia doesn't expose; forcing Principia to act like stock (instant impulses) and going through the stock manoeuvre node API works, but is unsatisfactory. We have an issue (#1659) to track providing an API to allow a PEG implementation to guide towards the planned trajectory; this will take us some time, but at least it's a well-defined and clearly-scoped feature request.

[eggrobin]

On 1/13/2018 at 8:42 PM, scimas said:

I've always wanted to ask this, and finally got to taking screenshots today. What do the various markers (pro/retro grade, radial in/out) mean in LVLH navball and where does the ship point when I use the SAS pro/retro grade, radial in/out modes?

  Reveal hidden contents

As you can see, I've target prograde, and in no frame of reference that I can think of should the ship be pointing radially outward from Kerbin and the navball showing radial in. The orbit is fairly circular and the second screenshot shows that even in LVLH frame, my velocity prograde should be about parallel to Kerbin's surface.

The SAS pointing to pro/retro grade in target frame is always off by a big amount when the distance is large, even when you do come close (within 200m) there's usually a slight difference in prograde marker direction and where the SAS points.

The markers are always the Frenet frame, see the concepts page. Specifcally, they are the Frenet frame of the trajectory plotted in the plotting frame. In this case, the trajectory plotted in the target LVLH currently curves away from the planet (as you can see on the screenshot), so the normal vector is away from the planet. In the Kerbin-Centred Inertial frame, the trajectory would be an orbit around Kerbin, which curves towards Kerbin, and thus the normal vector would be towards the ground.

Note that the Frenet frame that indicates the start of a planned manoeuvre in map view is that of the trajectory in the manoeuvre frame, not in the plotting frame: in this case your manoeuvre frame is KCKF, so the normal vector (blue line) points towards the ground.

We are aware that the SAS gets confused; we haven't really had the time to investigate that.

[Jim DiGriz]

Yeah so I worked at debugging this all night last night and figured out how to make it work, but it took some additional patching of the node executor in mechjeb (still patches sitting on my machine and not pushed anywhere or released that i'm testing).   In the flight planner you need to click "instant impulse",  "show on navball" and "inertially fixed".  This does three things.  It gives me a maneuver node to grab the trajectory off of ("instant impulse"), it fixes the node in the internal frame of the impulse ("inertally fixed") and models the node impulsively ("instant impulse").  The result is that if you click "display patched conics" to look at the keplerian tangent orbit coming off of the maneuver node that it very closely approximates the planned trajectory.

What PEG can do then is solve the finite burn problem of going from your unpowered coasting orbit before the burn to your unpowered coasting orbit after the burn.  The result is that e.g. I could hit the Mun with a periapsis of 46 km compared to a planned periapsis of 43 km, and burn 3-4 more dV of fuel compared to the 850-ish planned dV (so a 0.5%-ish penalty for the finite burn over the plan).  I need to add some kind of RCS to my vehicle and redo the test to see if that makes it better or not, but I suspect that the 3km deviation there is due mostly to the deviation between keplerian approximation to the target coasting orbit and the actual N-body orbit over the course of the burn (and possibly due to the impulsive burn not quite being perfectly impulsive).  At any rate, once I can poke Principia to get the real N-body coasting orbit from the planner then it should get very exact compared to plan.

I'll post an update once I get the code into a releasable (although probably beta quality) state.

[eggrobin]

8 hours ago, Jim DiGriz said:

At any rate, once I can poke Principia to get the real N-body coasting orbit from the planner then it should get very exact compared to plan.

At that point it should no longer be necessary to force the flight plan to operate in stock-like instant-impulse mode, so that should also make it significantly easier to use.

[影之瑒]

For now,Does The Pricipia  support some "JUMP" mod,such as ESLD Jump,FTL,or ksp interstellar?

[Jesusthebird]

Ive tried installing this, but every time, my game crashed when I try and load it up. the game loads to the main menu just fine. but as soon as I try and select my game. it crashes. Ive tried making a new save too. Ive deleted all of my planetpacks including GN as I thought that my be the issue. but im running relatively stock again and I cant seem to get it to work. Installed mods are as follow, through ckan(playing on 1.3.1:1891)

CRP

CTTP

Distant Object

EVEs core plugin(no configs currently)

Kopernicus

Kronometer

KSC Switcher

AVC full plugin

LSM

MFI

Planetshine

Poodsskybox

*This Mod* Principia

Scatterers Core plugin(no configs currently unless supplied by the planetpacks that arnt even installed currently)

Sigma88's: Binary/Dimensions/Replacement/DunaIke mods

TRR

ToadicusTools

 

LOG, I didnt get an output.log for some reason, I thought that happens only when the game crashes rather than a specific mod crashing(such as Kopernicus, and then finishes loading without it) 

[scimas]

7 hours ago, Jesusthebird said:

I didnt get an output.log for some reason,

There will be a folder named glog in your ksp directory. If the cause of crash was principia, then there will logs in that folder. Those will be helpful to the devs. 

[pleroy]

@Jesusthebird: We'll need the Principia logs to investigate.  Please see the FAQs for how to report problems.  Basically, what @scimas said...

Are you sure that you have downloaded the version of Principia that's for 1.3.1?  If you pick the version for 1.2.2, it will crash in mysterious ways.

[Jesusthebird]

13 hours ago, pleroy said:

@Jesusthebird: We'll need the Principia logs to investigate.  Please see the FAQs for how to report problems.  Basically, what @scimas said...

Are you sure that you have downloaded the version of Principia that's for 1.3.1?  If you pick the version for 1.2.2, it will crash in mysterious ways.

Ahh, ok was wondering about that. Yes, I downloaded the Clifford release for 1.3.1

Ive updated my onedrive with the glog files

https://1drv.ms/f/s!AjOhSRn-M-XfjTW9DTDBBNDiXDyj

 

Are there any other mods that this could conflict with?

[pleroy]

8 hours ago, Jesusthebird said:

Are there any other mods that this could conflict with?

Thanks for the logs.  From a quick look at them it seems that you are using a nonstandard solar system (I suppose that some mod does that for you) in which there is a celestial named DunaIke that has a zero rotational velocity.  This is not something that we support.  I don't remember the exact reason for rejecting this (I think it introduced unnecessary complexity) but it is never something that happens in real life: planets are not inertially fixed.

Do you have any idea what mod or config change could cause this?

[pleroy]

@Jesusthebird: So I suspect that Sigma is the culprit here.  From what I understand it's trying to do binary systems using the cheezy physics of the stock KSP.  To do that it creates a bogus body at the barycentre of Duna and Ike.  Then Principia comes along and tries to apply real physics to this mess.  This is not going to end well.  Even if we did not crash, the barycentre body would be shoved around and would not stay where Sigma wants it to be.

It should be possible to design real binary systems and Principia would make them work naturally, although as usual finding a stable configuration may be tricky.

The bottom line is that Sigma and Principia are mutually exclusive.

[Jesusthebird]

6 hours ago, pleroy said:

@Jesusthebird: So I suspect that Sigma is the culprit here.  From what I understand it's trying to do binary systems using the cheezy physics of the stock KSP.  To do that it creates a bogus body at the barycentre of Duna and Ike.  Then Principia comes along and tries to apply real physics to this mess.  This is not going to end well.  Even if we did not crash, the barycentre body would be shoved around and would not stay where Sigma wants it to be.

It should be possible to design real binary systems and Principia would make them work naturally, although as usual finding a stable configuration may be tricky.

The bottom line is that Sigma and Principia are mutually exclusive.

AHH!!! well, that makes me a sad panda. I love the binary systems. Oh well, at least we figured it out right? Maybe a joint venture is in order with sigma compatibility wise? I think it would be amazing to see these two mods work seamlessly. Tho I suspect it would require A LOT of rebuilding of both mods.

Cheers! and thanks for the response/explanation. I think I was getting brain trauma trying to figure that out.

[Sigma88]

16 hours ago, pleroy said:

The bottom line is that Sigma and Principia are mutually exclusive.

this

 

my mod is a hack to allow fake binaries in KSP physics, principia "hacks" ksp to use real physics.

I would say, principia should be able to provide binaries without the need of extra plugins, it's probably just a matter of setting the initial conditions correctly I would assume