http://cstart.org/wiki/index.p.....oldid=prev

http://cstart.org/wiki/index.p.....oldid=prev

http://cstart.org/wiki/index.p.....oldid=prev

http://cstart.org/wiki/index.p.....oldid=prev

http://cstart.org/wiki/index.p.....oldid=prev

http://cstart.org/wiki/index.p.....oldid=prev

I guess with this definition, something like "Project Rocket" would be a Program, and the different Stages within it would be Projects?

That's what I was thinking. Each individual "module" be its own "project". Programs are made up of multiple projects which are then used

concurrently to carry out the "missions" that the "stages" describe. Project Mannedflight would be made up of at least the RM and OM as it's currently stated, both which would be best developed as individual projects in the ODE. As the Wikipedia definition states, new projects could be added that are in the category of Manned Flight — such as a lunar lander, or a space suit.

A more complex example: what about CAD packages?  FEA?  CFD?  As far as I understand, commerical packages are much more suited to actual tasks.  [I hope no OpenFOAM, etc. users/fans jump on me for thsi!]

Hello, and welcome. I hope you are still following along. I have devoting most of my time with CSTART to working with OHKLA. I was away recently, but am slowly coming back to designing the rocket, and I hope that you will also contribute.'

As for CAD, I have been using Pro/E. Mostly because this is what is most easily accessible to me. I also have access to a few other applications, but not many. What are you most familiar with?

As for FEA/CFD, I have been using Ansys. In the past, I have done things such as determining an optimized nozzle geometry for the fluid flow of combusted fuel. This would have to be redone once we determine final lengths and diameter. It would be great to have your input on this as well.

The current state is that we do utilize proprietary CAD and FEA packages, but we also try to share the models via our google code project, which is far outdated and could use an update once more design decisions have been made.

I understand that a lot of restructuring is going on, but I am also keen on developing OHKLA in parallel, if possible.

Luke Maurits said:

Thanks for doing that little bit of analysis, rpulkrabek.  When you say you set the inside temperature to 1000 C, exactly what do you mean?

I set the inside of the aluminium combustion chamber to be 1000 C. I would have rather set the fuel to be at that temperature, but I would have needed to know the convection coefficient, which, I believe, is determined experimentally. In any case, I feel that the high temperature of combustion is too much for aluminium.

My gut feeling is that it is best to move forward with using phenolic insulation. I don't know much about it, but I think we will be able to put a thin layer between the HDPE and Aluminium. I think this thin layer of phenolic insulation will be much less massive and take up much less volume than planning to leave unburned HDPE. But, I don't know for sure. I would like to find out more about phenolic insulation first.

With that said, can anyone provide information about phenolic insulation? How is it used? How expensive is it? How efficient is it? How much heat can it withstand?

Antinode, I agree that simplification, where possible, is very important.  As Greg pointed out, some of those tabs are in the screenshots because we wanted to see what they were, not necessarily because we thought they should be there.  The question about calling project related work "issues" or "tasks" is one I am on the fence about.  I am not sure I like either very well, but could live with either if other folks were attached to one or the other.  If I think of a third option I like better I'll be sure to post it.  

Regarding files, wikis, documents, and repositories...  This is actually something that I think we need to work on a little bit more.  I have seen engineering teams try to cram their work into traditional source code control systems (SVN, bzr, etc) and for anything beyond small projects it just does not seem to work.  Too many of the files that are generated are one off things such as wind tunnel data or the results of a CFD run(so version control is not exactly helpful).  Those that are good for versioning are often binary files (which is something source code control systems really are not geared toward handling either).  And then there are the large files (video, CFD or FEA output files, etc) which can be in the GB size and will break most source code control systems.  And all of that is before we talk about how best to organize the files with respect to projects and sub-projects or what content should be stored in files and what content should be in the wiki (for easy editing and sharing).  Like I said, I think there is some work to be done here.  I will try to put together some concrete examples to discuss over the next few days.  

Luke, regarding a version 0.0 of ODE that focuses on the basics and then working toward adding in project management tools...  This is what Mach 30 folks concluded was the best course of action when we were discussing this in house.   I think our primary reasons were that the scale of projects we will be starting with don't strictly require a sophisticated management tools and as you pointed out using the tool will hopefully inform us about what kinds of management tools we really need in ODE.  Here are the minutes from the meeting where we discussed this last at Mach 30.

Like I said, I'll try to put some examples about content storage together soon.  Until then...

Programs are made up of projects. Projects also have start and end
dates and are specific to deliverables, whereas programs do NOT have a
specific end date as they are created to meet a strategic or tactical
aim. e.g Program might have a main objective to improve customer
service and there will be more than one project created to meet that
aim such as project to improve delivery times, project to shorten wait
on phones, project to create and ringback and follow-up. New projects
are added (and removed) depending on changes in strategy, budget,
resources and are prioritised accordingly.

I guess with this definition, something like "Project Rocket" would be a Program, and the different Stages within it would be Projects?

I've been thinking more about the program/project thing.  I don't know how universal this is, but to me, "program" has connotations of a long-term endeavour, with lots of individual steps, with an uncertain total duration.  The "X Program" sounds like it should have "X 1", "X 2", etc, for as long as it takes us to complete the program's goals.  In contrast "project" sounds to me like more of a one-off, clearly defined effort without subdivisons.  Do other people have this intuitive understanding?  If so, how do we think this applies to our projects/programs/whatever.

On the one hand, the currently proposed 4 projects/programs do have a stage structure, which is inline with the pluralistic interpretation of "program".  On the other hand, I envision them as being efforts to produce the technology to enable other projects/programs which will be even more program like.  E.g. once we have a proven generic CubeSat infrastructure, we might decide to use it to investigate some specific scientific phenomenon, and that could be a long term endeavour that we don't immediately know the duration of - we might have to keep laucnhing ever more advanecd satellites as part of that Program until we finally have all the data we need for our purposes.  Compared to something like, something like "Project Rocket" seems fairly limited in scope.

Perhaps I'm making too big a deal out of this.  What do other people think?

I notice that NASA don't seem particularly consistent in their use of these words.  This page seems to use some definitions whereby "Project Apollo" was a "Program", which I consider somewhat confusing.

J. and I have had many discussions about exactly how much management support this tool should provide.  Where exactly is the line between design work & project management and how does systems engineering process apply here?  I think schedule and budget are reasonable discussion topics when deciding on which features to include.  I can think of reasons to include these features, but also understand the desire to simplify version 0.0 and develop a core capability first, on which to build.

I think that this is probably going to be one of the hardest things about this project to get right.  Everything else, like management of files and repos, issue lists, Wikis, discussion and messaging, etc. is relatively clear cut compared to high level project management.  I do have to admit being tempted by the option of going ahead with a 0.0 version which leaves most of this out and adding project management stuff slowly as we get experience using the 0.0 version (and hence get an idea about which project management features are most needed), but I am aware that if we have some ideas from the start we may be able to design the general architecture of the app so as to better facilitate the later project stuff.

I'm still undecided to the use of a seperate project Wiki. I think it would make more sense to have the top level "Wiki" information be contained on the project overview/landing page, which contains links to the subsystem pages, rather than having two seperate project info pages.

My biggest concern with per-project Wikis is that if the work involved in each "top level project" (e.g. projects like OHKLA, CLLARE) is divided up into sub-projects (and I think we are all in agreement about this being a good way for things to work), it means that Wiki material relevant to a single top level project will be extremely scattered.  There won't be an "OHKLA Wiki", there'll be an "OHKLA Propulsion Wiki" and an "OHKLA Avionics Wiki", etc, etc.  I think it would be best to have any Wiki-esque material for a given top level project in a single Wiki, for the sake of simplicity and clarity.

I don't know a tremendous amount about the various chemical and physical processes involved in most ISRU ideas.  I believe it is true that all the elements will have different resonant frequencies, I suppose the question is how high those frequencies get for the sorts of elements that are present in regolith, and whether generating RF at those frequencies would place realistic demands on power supply, etc.

ISRU is interesting in that, to some extent, it's something you can plan for and practice on Earth for (relatively) low cost.

I think the currently proposed set of 4 projects based around foundational technology actually provide a sufficient tree root or set of roots to cover just about everything.  The rocketry project covers, well, rocketry, the CubeSat project will cover vacuum electronics, comms, etc. and the minimal manned spaceflight project will cover things like life-support and heat shielding.  Between those bases I think by scaling things up we could cover most applications, certainly minimal space stations.

The one thing which comes to mind as being completely not covered yet is robotics.  Presumably at some stage down the road we will be looking at things like very basic rovers, sort of reminiscent of the miniature rovers people are proposing for the Google Lunar X Prize.  We don't have anything to cover this yet.  This probably isn't a big problem because it's quite a distant goal, and also I suspect perhaps less amenable than other technologies to standardisation (in that different landing locations and mission purposes could require radically different concepts).  Still, something to think about.

If nothing else, a tech tree could be, like you said, a compelling way to visually represent the interactions between all the projects.

Thanks a tonne for that hackerspaces.org link!  It seems like a hackerspace has finally opened up in my city since the last time I checked!  I'll definitely check out their next meeting.  If it seems like a good place and that people might be interested, I may bring up CSTART.

I recalled that one of the problems in the original moon missions was a build-up of lunar dust that was highly abrasive, being attracted to the astronauts and their equipment because it was photo-ionised.

I've seen the entries for NASA's lunar mining robot contest, and it occurred to me that this property might be exploited, and avoid readily wearing moving parts too!

I imagine a mining craft moving to a certain position and embedding a spike or auger into the bedrock to ground it, then extending either a directional funnel or "trunk" lined with panels to electro-statically attract the lunar dust. Essentially hoovering it up.

I suspect with careful design, electrical fields could at once draw the dust down the collector and repel it from it's surfaces. Possibly some sort of peristaltic motion.

Actually processing the dust is another matter entirely, though I have wondered since there is a hydrogen resonant frequency (as exploited in microwave cookers), there must be resonant frequencies for other elements. And perhaps in a low-gravity and electro-statically confined environment, this could be used to create some sort of microwave fractional distillation column?

Depending on the dust content though, perhaps it could simply be printed and sintered into 3D objects? Or a combination of the two; separating into various powders for more precise sintering, etc.

If the latter is possible, by combining both in one machine it could drastically reduce the amount of equipment requiring transport to the lunar surface to set up automated manufacture there.