Smermel Int

Ok, here goes…

I. I consistently have issues downloading the new data pack. It makes it 51% - 53% of the way, and dies. Here's the charming message I get:

~smermel/Attic/EDGE_data_pack_v1.1.tar.part could not be saved, because the source file could not be read.

Try again later, or contact the server administrator.

Note: This got fixed by y'all delivering a DVD to me

FIXED: The pmwiki downloader timeout setting needed to be bumped up. Also, make sure you use firefox and not Internet Explorer for downloads.

II. This brings up some questions. The release notes says not to mix v1.1 data with v1.0 data. So, I shouldn't just point the link to v1.0? (I may try that with a readonly file. It couldn't hurt in that case.) I remember you mentioning that the latest available data isn't as high resolution as what we've got. Do I want to use the version 1.1 data then?

Note: Moot point, now that y'all delivered the DVD to me.

frankie August 13, 2007, at 03:38 PM: What I meant by the "latest data not being as high resolution as what you have" was that the latest data from the USGS website… not from the EDGE release. If you null out your earth.map and make it writeable so that the data gets rebuilt from the internet, then you will find that most places no longer have hi-res data available. This is just the state of the USGS website… so this could change later.

III. The userdata directory. The theory is, just remove yours, put mine in, and all is good. Just wanted to confirm that that's what we should do. I still think you should make the userdata directory be a symbolic link in that case. You can provide a sample of the userdata directory, but a link would help reinforce that it's a separate entity from the rest of the EDGE tarball.

KEITH: In practice my userdata is a link. Packaging a link seems like it could cause confusion. I don't know. We are assuming a base pkg (CEV) and using userdata to make local mods (or overriding the entire base pkg). I like the idea of assuming a base which is completely generic, and having the CEV package a component. This arrangement would require some kind of chaining of components, like CEV + Chutes. Just thinking outloud.

frankie August 13, 2007, at 03:38 PM: We didn't make userdata a link, because we didn't want to force people to change the link to customize… the idea was to have a userdata dir that had the skeleton available for customizations, but didn't actually change anything, and the let the users add their customizations in there. I guess there is a different mindset for people using it for the first time, and people upgrading from an earlier version.

But in the upgrade case, just rename userdata that is delivered and then do whatever you want… make a link… make a directory… or change the variable that points to your userdata dir.

I notice there's some changes, but they're probably my own: : * I've added a kill_graphics into userdata. There are differences though, so that makes sense. (You might want them. It makes the script less deadly to things that aren't directly DOUG related. Here it is!)

KEITH: I added your script to the user contributions. Thanks!

: : * I have a solarsystem directory in my old userdata. I'm fairly certain that came about as part of the simdata plugin.

frankie August 13, 2007, at 03:38 PM: Actually, that is not delivered. That is part of the astropix/kepler plugins from Tom

: : * I have a states directory in my old userdata. I know I made this on my own, to hold my new base state. You might want to include it in yours, though.

frankie August 13, 2007, at 03:38 PM: Good idea. There is actually already a suggested setting in userdata/user_env.csh to set the "DOUG_STATE_DIR" to "${USERDATA}/states", but we didn't actually make the dir. Added as issue 00051.

That's a cursory glance. I'm thinking I'll just have my userdata bludgeon yours, and deal with the consequences as they come. Main point of this bullet point - is there anything I should be looking out for in the userdata directory?

Turns out there is. Here's the deltas that are in 1.1 userdata but not in my modified 1.0 userdata:

Having checked more carefully, I've found these deltas:

• reconfigs/input.USER has changed near the bottom. Instead of the SOLAR_ARRAY_ALPHA and TRRJ_GAMMA reconfigs, you simply left a comment about the flags such a reconfig would take. (I copied the flag comment into my existing file.)

• user.cfg has a few places where you've added comments a la "this is a good place to…" I don't know if those are new or not, but I don't have them (anymore) in my old version.

• simdata/README didn't exist in the old userdata. I copied it in.

• user_env.csh has significant additions of SIM_DATA_DIR and DOUG_STATE_DIR, which then required a (simple, since it's such a small file) merge. I'm glad for the new variables in the file, but would have blown them away if I blindly copied my userdata.

frankie August 13, 2007, at 03:38 PM: Actually, it wouldn't have mattered… these lines you added are commented out.

Still, not bad… it was fairly easy to copy userdata over safely. I wouldn't mind a delta-list in the future, though.

frankie August 13, 2007, at 03:38 PM: Well that is what I intended the release notes to be. There was only a few comments in this case, so I didn't feel like any changes would have broken anyone… you should be able to copy in your userdata into the new release and run. I do want to list any changes that you would have to make to your userdata that aren't backwards compatible, and I intend to do this in the release notes. Let me know if you find something that doesn't work in 1.1 and I will add it to the release notes under the "Upgrading" section.

smermel How'd you get it to autoadd the date? Regarding your two previous notes — maybe add a "new variables available" section to the release notes? If I had blasted out your userdata without merging, I wouldn't have known that those two variables, albeit commented out, existed. I (very happily) used them as soon as I saw they existed - and never would have known in the standard case you describe. Ideally, I'd like to see a bullet point for any change you make to userdata.

IV. While I'm moving the data pack to where it needs to be, I start wondering about the elevation data. Which is awesome, and I'm thrilled it's available. But there was slight mention of it in the release notes. Will there be more? Or is it all magic-happy-self-explanatory?

frankie August 13, 2007, at 03:38 PM: Hmm… not sure. There could always be more :)

smermel I need to learn how to autoadd a date: So, I did an entry run, landing at whitesands. The CM still seemed to hover thousands of feet above the ground. Other than seeing the elevation map be read in, I saw no evidence of elevation data being used. Am I missing something? A plugin? A .cfg entry? I have no idea.

Had to run away. Duties outside of work called.

---

Wanted to run away. Spent 5+ hours in meetings. Now that I'm back, let's see…

Yesterday, just before leaving, I copied over my old userdata, and typed run_graphics in the appropriate directory. Things seemed pretty ok, except that the earth was a solid black ball. I was informed that I needed to change some of my PLANET2 reconfig. Which was unfortunate, since in my previous userdata, I set my reconfig to overwrite the standard one, so that I could change the parachutes. Now I needed to change things around. Did I have to copy/paste the standard input.USER to mine, like last time? I waited with baited breath, and looked into it.

And the new input.USER is nice. It obviously includes stuff based on environment variables, letting me scapel in my new chutes reconfigs. All I need to do is set RECONFIG_CM_parachutes to point to my file instead of theirs. Question now is… what sets that variable? It wasn't in user_env.csh, but I did find it in .doug_cshrc. It probably belongs in user_env.csh. That's certainly where I'll be overwriting it. *:-]

frankie August 13, 2007, at 03:38 PM: Yep. Most things are not in user_env.csh, but everything can be overwritten there since it is sourced last.

And, other than a typo, it worked ok. For some reason, I had PLANET_SHADING toggled off. I'm not sure why I had it off, but toggling it gave me a nice purty Earth again. And here I was, getting used to living on a big black empty ball…

frankie August 13, 2007, at 03:38 PM: This could be because you are using you own base state and some nodes have been added to set the position of the sun and whatnot. I'll add "regenerating a customized base state" as a step in the upgrading notes for that.

I brought up the handy-dandy sim_data dialog. It looks nice and new and sleek. I like that it doesn't ask for header files anymore, and that it used the environment variable to look at my userdata setting. I loaded up one the stock runs for a nominal insertion. Looks pretty good, other than showing off that weird bug of jumping to the first frame of movement data. I think that's on my side, but I still haven't fixed it.

So… this old CM and SM that I keep seeing makes me wonder: "When will I get a prettier CM and SM to look at?" I've seen preliminaries of models coming down the pipeline from ER. Are we there yet? Are we there yet?

frankie August 13, 2007, at 03:38 PM: If you have any updated models, please let us know.

smermel However did you autoadd a date?: I was sent preliminary ones from the ROC, and then told they were thinking of distributing them through you. Was it all a dream?

At this point, I don't know anything else to do, other than bite the big bullet and merge the model pack in to ANTARES. This will be non-trivial, because I've been making lots of changes all around it, including the way the plumes are cared for. I probably won't finish it tonight… Before I left to do that, though, I looked inside the crew module. There's now an even cooler crew figure in the right seat. I had fun turning him/her on and off. Ok, now on to the ugly merge…

---

The merge isn't too bad. There are no more than 10 files in the model pack where the fine DOUG folks have made changes, and so have I. While none of them are excrutiatingly complicated, I do need to manually merge each of them. I thought at first I'd have to change all the .d's to use the new Trick alloc syntax, but that's already been done for me.

Ok, so far, the merge has been very straightforward. My only beef so far is in model_pack/generic/src/drive_orbital_graphics_elements.c. The C compiler doesn't like the double ** syntax, and nor do I. Technically, it's wrong. And the lvlh_rot_matrix = &(G_OUT→T_inertial_lvlh) sort of thing is definitely wrong. It works ok because of the nature of pointers, but the proper syntaxes are:

double (* lvlh_rot_matrix)[3];
...
lvlh_rot_matrix = G_OUT->T_inertial_lvlh;

It would be really nice to see this sort of thing fixed for the next release!</Blatant hint>

frankie August 13, 2007, at 03:38 PM: Good point. I had taken care of this for the input pointers (to point to the 2D arrays for input: see the "UNION_2D_ARRAY_PTR" data type for details), but forgot/neglected to do it for those two local variables… I've added issue 00052 to fix this under your name.

And, while I'm at it, we've made different forms of update_plume_elements.c. Mine has a for loop. Actually, you'll have to take my plume stuff at some point, anyway - we need to drive more plumes than what is released in your model pack. You can grab it from the next ANTARES release, or just let me know.

Well, in hindsight, it seems that the model pack wasn't too tough. Minor tweaks all around, but nothing huge. It occurs to me that the thing I'll need to do next is make sure that all the files in userdata that override any of yours still should. Because, inside the model pack, I didn't see anything at all for your different way of driving plumes.

Ooh! It's in your gui, and I don't apparently override it. In theory, then… everything works.

Let's not test it. Let's just believe.

Oh. The names have been changed, to protect the guilty. It used to be CEV_ascent.tcl. Kinda glad it changed its name. We use plumes everywhere. But that means I will need to merge up. The biggest deal is that I need to tweak cev_plume_array.tcl, but can't without copying everything that depends on it. The path to that file has got to become an environment variable for next time.

Yeah. Your changes and mine will work seamlessly, except for that lack-of-environment variable. Because of that, I'll have to copy-paste all three of those files into userdata/gui.

Actually, I didn't have to. The old cev_ascent drives it on its own. If I don't play with my user.cfg, I get the plumes driven exactly as I needed. However, it wasn't too tough to get rid of that, copy your new cev_plumes files, and add the new plumes I need watched. I need to put it through more thorough testing, but for now, it looks like everything works fine!

---

I've put it through some ringers. I still get it to core dump when I run the sim and send a SIGINT to DOUG. And I don't know what to do to make the elevation data work - my landings at White Sands still hover high up in the air. Other than that, I'm happy. We should be shoving this in to ANTARES 7.4.0, coming out very soon.

frankie August 13, 2007, at 03:38 PM: Very cool. All good questions and comments.

smermel I still don't know how to autoadd the date: Yay for the good release! On the wiki level, this page is no longer displaying pretty. (I'm using IE 6.0.2900) Once Frankie added his comments, it started looking ugly.

frankie August 17, 2007, at 02:11 PM: Friggin' IE!! anyways, I think I fixed the IE problem. Also, putting three tildes like (~~~) will convert to a signature like this: frankie and putting four tildes like (~~~~) will convert to a signature like this: frankie August 17, 2007, at 02:11 PM