[16:57:18] NASSP Logging has been started by n7275_ [16:57:20] hey alex [17:04:22] hey [17:17:18] Hey guys [18:16:11] morning! [18:40:27] Hey Mike [18:45:35] what's up? [18:49:09] Been looking for documentation on the ATMDC and am sure that NARA has some interesting ones. Ron has scanned a document listing which documents were transfered to NARA from the JSC including box number back in 2004. [18:49:36] NARASW has moved to a different location in the meantime though so the boxes might not match anymore. [18:50:37] oh yeah there's not a lot of info about that out there is there [18:51:00] I think at one point I figured that there might be some drawings of it in NARA's 40Mxxxxx series [18:53:36] So far I found "Skylab JSC ATMDC Program Notes, PCN-1 and 2", "Skylab ATMDC Flight Program Software Interpretation Handbook (Rev. A)", console handbooks, verification plans and results reset data and paramaters for the RTCC programs meant to update the ATMDC, ICD for the ATMDC in the Skylab simulator and it looks like requirements for the nav and timing equations [18:54:57] https://www.ibiblio.org/apollo/NARASWoverflow/E156L.pdf [18:56:13] Unfortunately I don't think NARA currently scans anything due to COVID right now [18:58:56] yeah they're not [18:58:59] which has been endlessly frustrating lol [18:59:21] I wonder what the interpration handbook is about. It almost sounds similair to the symbolic listing information document we have for the AGC [18:59:30] if so that would be awesome [00:30:52] looks like Ron's been busy. [00:57:54] yeah, I'm glad he's trying stuff out and trying to come up with other explanations :) [01:03:04] I'm kind of curious if he's going to attempt to annotate Luminary 178 at some point lol [16:46:49] hey [17:00:31] hey Alex [17:04:48] I'm getting closer to implementing a good way to initialize the RTCC for both the MFD and the MCC [17:04:59] from the user perspective not much should change [17:05:17] but I am putting lots of numbers in text files right now haha [17:05:33] each equivalent to a tape or a stack of punch card that would be loaded into RTCC memory [17:05:38] cards* [17:08:57] there is one tape with all the mission constants. Those are in files like "Apollo 11 Constants". But only when the different from the default [17:09:28] like Apollo 10 launcing from LC-39B, so launch site coordinates in the RTCC are different [17:09:42] AGC uplink addresses are also RTCC system parameters [17:32:16] right makes sense [17:35:30] and also files for the skeleton flight plan [17:35:36] and TLI simulation [17:35:51] right now it needs to read the TLI sim parameters directly from the LVDC [17:41:47] for an alternative launch day you won't have to change any code [17:42:22] but you will have to manually change the launch day and time of launch on the config page I think [18:09:15] morning! [18:19:16] hey Mike [18:19:40] I've become as crazy as you, I'm doing punch cards [18:23:02] hahahaha [18:23:07] what for? [18:23:31] well kind of [18:23:47] I'm putting all the values the RTCC needs to simulate TLI in a text file [18:24:12] and the format for it that I have chosen is the same as the punch cards MSC used to load the RTCC with it [18:24:23] 4 values per card, so I am doing 4 values per line in the text file [18:24:35] https://i.imgur.com/MldAjdp.png [18:25:34] hahaha excellent [18:25:35] the document where I got this from also has the format of the tape that MSFC is sending to MSC [18:25:55] but this card format is closer to the table as it appears in the RTCC software [18:28:14] yeah punch card formats are definitely the way to go [18:28:20] speaking of I'm super close on Aurora [18:28:24] just 40 pages maybe left [18:29:35] awesome [18:31:07] I also have the format for the midcourse correction processor values [18:31:14] they did leave some space for expansion [18:31:23] which they did need [19:13:26] Hi all [19:16:16] I've been thinking about this diff.eq. issue what n7275 had come up with. Also looked into the code of PanelSDK [19:20:58] And currently I think the employment of the standard ODE methods (Runge-Kutta, Adams-Bashfors, etc.) will not help too much here. They are good for diffeqs where the dependence of the variables are pretty smooth ("differentiable"). But in case of PanelSDK there are quite many non-smooth effects, like valves opening at certain pressure limits; [19:20:59] hitting constraints like emptying or saturation of tanks, etc. [19:37:29] My advice would be here to use some sort of "pathwise Euler" where a very similar method to the current is used. But first all derivatives (like flow rates, heat rates are calculated) are calculated (so the diffeqs left and right side is clearly separated). Then we test whether any discontinuity happens (e.g depletion of a tank) during the given [19:37:30] dt interval. If no, then procceed with normal Euler. However, if yes, then find the last timepoint within the dt interval, where the Euler method wouldn't lead to discont (lets call it dt_0). We recalculate the right side (the flow rates) at dt_0, and finaly, repeat the procedure for the [dt_0, dt] intervall. [19:40:04] If any of you could send me a scenario with an example of overshoot, that would be great as I can experiment with it how this pathwise Euler would improve things. [20:10:01] hey ggalfi [20:13:31] so at dt_0 wouldn't that be the exact time when the depletion of a tank happens? [20:14:42] and I guess we do something similar in some places already, where the code doesn't allow more than 10% of the content of a tank to move during one timestep [20:15:05] but your suggestion would be something that applies to the whole system I guess [20:19:45] yes dt_0 is the exact timepoint where the depletion would happen based on Euler method. And yes if any depletion would happen, I'd recalc all the flowrates (to avoid less unloading on one end of a pipe than the load on the other end). [20:21:04] What I've seen in PanelSDK code, that the integration happens in pretty ad hoc location and the overall consistency isn't taken care of. [20:22:10] But I don't want to say I understand every subtleties of the code, so it could happen that it is taken care of. Just I haven't seen it. [20:22:48] nobody understands all the subtleties of it, which is part of the problem haha [20:24:33] It is a pretty complex thermodynamics simulation, so anyone had made it, he or she done a great job I think. [20:25:23] I mean the way it gets updated is by running the refresh functions of all parts of the simulation in order [20:25:40] the order in which they are defined in the systems config file [20:26:03] tanks only calculate changes of their contents, temperature etc. [20:26:06] pipes do the flow [20:27:07] so you want to see something unstable hmm [20:27:30] when we couldn't achieve that in a good way we simply forced the systems to have a shorter step length [20:27:42] e.g. top of LEM::SystemsInternalTimestep [20:28:05] that calculates how long the step length is allowed to be [20:28:21] so that makes even the pretty bad LM ECS fairly stable [20:28:46] just use a scenario with the LM fully powered up [20:28:50] e.g. Apollo 11 before PDI [20:31:46] when we couldn't achieve stability* [20:35:40] Can you tell me a parameter which shows this behaviour? In "astronaut mode" the ECS parameters look normal in that scen. [20:37:53] glycol pressure was fluctuating quite a bit, although that is better now with the shorter step length [20:38:23] pressure in the suit loop was also bad [20:38:36] lots of tanks in a circle with fairly large flow rates [20:47:38] Ok i'll look at it. [20:51:59] you might have to change the code at the top of LEM::SystemsInternalTimestep to "unfix" the stability [20:56:44] Ok, thx [20:57:20] in LEMSystems.cfg [20:57:25] the suit loop tanks are [20:57:46] ah there is a commented line there [20:57:47] # Suit Circuit Tanks [20:57:50] the tanks below that [20:58:03] I think they used to have flucuating pressure really bad [20:58:28] the overpressure valves are implemented so we actually lost O2 on the way to the Moon due to that [21:01:45] and with the glycol pressure, you can still see it changing with time acceleration [21:02:23] just look at the needle [21:11:48] AlexB_88, I taught the MCC to use the MPT and simulate TLI properly [21:11:53] now what do I do with that... [21:13:00] nice [21:37:43] hey guys [21:43:36] hey [21:47:29] Oh wow. [21:47:31] Hey n7275_ [21:47:46] Finally figured out why my console wouldn't connect. [21:49:16] I told the program to connect to localhost:3270. What happens is that gets resolved as ::1 and since hercules only listens on IPv4 that connection got refused. Instead of the program doing another attempt to connect to 127.0.0.1 it just quits. [21:50:27] So grateful that wireshark exists [21:53:58] ahh, makes sense [22:16:07] Hah, this is pretty cool. IPLed MTS and managed to log in on a user terminal and create some text files. [22:18:14] I think I'm more or less, finished with the nitrogen part of the fuel cells. may revisit for supercritical fluids in the storage tank [22:23:05] @Thymo, cool. so when are you porting over the RTCC? :) haha [22:23:33] I just downloaded Hercules again. may play around with it tonight or tomorow [22:29:07] I have played with the idea of having a public Hercules instance running on my server that can do RTCC/Apollo related stuff. :P [22:29:45] One step at a time. I need to understand this stuff better first. [22:33:04] I suggest we find RTOS first [22:39:01] night! [22:55:31] someone finding a dusty old box of RTOS tapes and publishing them would be great.