Back To Top
When I try to login anonymously to Amino CVS, I get booted-out:
Parkers@parker1 ~ $ cvs -d:pserver:email@example.com:/cvsroot/amino login Logging in to :pserver:firstname.lastname@example.org:2401/cvsroot/amino CVS password: cvs [login aborted]: end of file from server (consult above messages if any)
Fix: This is a strange quirk with CVS (for all of SourceForge, not just Amino's access) What you need to do is simply keep trying. The author has had to try around 20 times in the past, when the server is especially busy. if you're using WinCVS the author hasn't had experience with it - see the WinCVS site if you're using cygwin you may get an error referring to /home/<user>/.cvspass - you may try creating a file of that name in that dir and putting this line in it: :pserver:email@example.com:/cvsroot/amino A (this is unverified to fix the problem) You may be able to forego the login command and do the following: cvs -d:pserver:firstname.lastname@example.org:/cvsroot/amino co Amino (and you'll need to repeat that for Simtein and tools modules.)
I get the following error when I download from CVS and build all:
Parkers@parker1 ~/Amino/Amino/ant $ build.sh Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/tools/ant/Main
Fix: Verify that you have the following: 1) downloaded the tools module from CVS, or that it was in the distribution zip file. 2) looked in tools/ant and verified that is has lib and dtd subdirectories 3) edited the build script you're using, and added an echo command of the data used for the '-cp' option to the java command, and verfied that that CLASSPATH properly contains ant.jar If this doesn't help diagnose the problem, please send a question to the list: amino-folks_at_lists.sf.net (replace '_at_' with '@' in your mail application)
I get the following error when I run build.sh run-gol in the Amino-<version>/Simtein/ant dir:
Parkers@parker1 ~/Amino/Simtein/ant $ build.sh run-gol Buildfile: build.xml run-gol: run-localimpl: [java] java.lang.NoClassDefFoundError: com/sparker/amino/Main [java] Exception in thread "main" BUILD FAILED file:C:/Amino/Simtein/ant/build.xml:384: Java returned: 1 Total time: 8 seconds
Fix: Verify that you have compiled Amino module in current mode (look in Amino/ant/amino.properties for the mode path settings, verify that the proper jar file is in the Amino/lib dir). If this doesn't help diagnose the problem, please send a question to the list: amino-folks_at_lists.sf.net (replace '_at_' with '@' in your mail application)
How can I avoid the complexity of being distributed?
What’s the simplest configuration for running Amino?
Fix: If you do not want to be using OpenORB, or you have not installed it, edit the file Amino/ant/amino.properties and set the settings interface.path=local and implementation.path=localimpl. This turns off usage of all CORBA and OpenORB facilities, including the IDL compiler. Only classes in the <module>/src/local and <module>/src/main (and test) will be available in the ant CLASSPATHs. Note: You may need to rename or delete the existing build subdirectories of ALL modules, and rebuild all modules.
I get the following error:
$ build.sh build-main Buildfile: build.xml init: [echo] --------------------------------------------- [echo] Amino <version> [echo] Creating build directories ... openorb-idl2java: [echo] Generating stubs from src/idl/amino_core.idl ... [java] java.lang.NoClassDefFoundError: org/openorb/compiler/IdlCompiler [java] Exception in thread "main" BUILD FAILED file:D:/sparker/Amino-0.2.0/Amino/ant/build.xml:362: Java returned: 1
Fix: You’ll need to edit the file: Amino/ant/openorb.properties and set the openorb.root value to be the directory where you’ve installed the OpenORB modules. If you do not want to be using OpenORB, or you have not installed it, edit the file Amino-<version>/Amino/ant/amino.properties and uncomment these two settings: interface.path=local implementation.path=localimpl and comment these two settings: #interface.path=idl #implementation.path=ooimpl Save the file and try again.Back To Top
When I run an application, it doesn't seem to do anything...
Fix: Most applications will put up the GUI, but do nothing else. It's up to you to open windows, run the simulation, etc. Experiment with the mouse buttons and see what menus appear when you do different things. See the User Guide for more information.
How Do I Get started? I'm new to Open Source/Modeling & Simulation...
Answer: Ideally, when people want to model something in Amino they'll take one of two approaches, each having dis/advantages: 1) They'll use existing classes (ie. Model or PhysicalEntity) and simply distinguish them in their model by using specific properties; 2) They'll create specific sub-classes of Model or Physical Entity and add methods and/or specific properties. Certainly for 1) they need to understand the system to some extent, and for 2) they need to understand how to program Java and understand the system. The easiest thing for a user is the following scenario, and a goal that I have for Amino in the long-term: 1) a user fires up Amino and want to model automobiles in various traffic situations (they have on hand a set of differential equations they want to use, for example) 2) The user creates an Algorithm object, or more than one, and populates the Algorithm with mathmatic expressions; 3) The user sets-up the in-ports and out-ports for the Algorithm (these form the basis for the Algorithm to test which connections are valid to it, and provides the math inputs for the Algorithm, and defines what the algorithm will change in the process) 4) The user sets up a prototype Model object, say a "car" and defines it's properties as "position", "velocity", "length", etc. 5) The user defines other things, like the dimensions of the roadway, etc (this is used for constraints on the math algorithm and for visualisation, if desired) 6) The user could save this configuration as "my automobile simulation" - this is basically a re-loadable data structure (XML Stream) that could be the default configuration/starting-point for the simulation when Amino is started-up; 7) Then the user could run the sim, and put up plots - auto-density vs. position, avg speed of vehicle vs. position, etc. So this is one example of the "potential" of this system. Of course this is not possible at the moment, mostly because the GUI commands have not been set up - however, most of the back-end building-blocks are there. For now, obviously we're starting small. That's one reason I made the GOL first - it has a trivial algorithm, can be easily displayed, is easily confirurable, and has general appeal to non-scientists/engineers. It was a theoretical exercise to begin-with (when John Conway came up with it) so it doesn't have practical application per-se - but We'll use it as our initial example for adding new types of sims. It's an example of #2 in the first numbered-item-list. Nothing in the code/design prevents this scenario from being implemented, it's just a matter of having time to do-so. So you'll simultaneously want to refer to several resources on the Amino web-stie - the UserGuide (under 'Using Amino'), the javadoc (under 'Contributors') and the GOL source code, under Simtein/src/gol/com/sparker/gol/model (1 class) and Simtein/src/gol/com/sparker/gol/cont (1 class). The two classes work in concert in that one depends on the other for specific information/properties. The GOLAlgorithm is not using the in=port/out-port stuff yet, I'm planning on shifting stuff around slightly to make it fit the above scenario a little more closely (it's not too far off right now) Also, a generic Model is being used to hold specific properties, so this really is a combination of the #1 & #2 items at the beginning of this email. The GOLModelManager's task is to define the system at start-up. This involves creating a GOLAlgorithm, and adding to it children Models, each with a position, state, and color. When you run the sim via the GUI, your instructing the SimulationManager (not GOL-specific) to step-along, telling GOLAlgorithm each step. The GOLAlgorithm does it's calcs, setting the child Model states. The GUI gets this change notification by the DataChangeListener mechanism set-up behind-the-scenes (when the Models were added to the Views) So the only way the GUI knows to draw different colors is because the View got the signal that the Model properties changed. Here's what's nice about this situation: 1) the view doesn't care that it's drawing cells (well not really, I have a tiny bit of work to do on this :-) 2) The Model is generic, and simply holds properties. No coding required in order to change Model type code. 3) The Algorithm could be made generic if it has the ability to process equations/statements. The GOL algorithm can be represented using MathML for example. We'd just have to come up with the code to process MathML, build a statement structure that can be evaluated, and come up with patterns of handling children within the Algorithm. (I've done a lot of this type of work at my last job) 4) The SimulationManager doesn't care what kind of Algorithm is being stepped, or even if it's being viewed. The framework handles passing info around without being dependent on the sim type. The big idea here is to "decouple" the parts of the system so they can vary independently - in implementation, and in state, and have the information get passed-around so it performs some task. Mind-you - this is not a new idea! I'm not coming up with anything novel - not until the following is realized: 1) we could model multi-disciplinary systems in the same sim; 2) the collaboration between engineers in real-time allows complex systems to be changed on the fly, during run-time if necessary, to observe behavior of dynamic systems; 3) Amino has models that are fundamentally different simulation schemes - allowing differential analytical solutions, newton-raphson step-wise simulation, discrete-event-simulations, parallel processing (and discovery of parallel independent paths), maybe even monte-carlo simulations, and 4) this being a free open source software that people can use without paying big bucks! Please don't get overwhelmed, or even scared! These are my ideas of how this could evolve - they don't represent the current complexities of the system. The idea is to have a simple system that can do complex things. That's why Amino-core and Simtein are separate modules in SourceForge - so they separate different architectural layers and have small responsibility-sets. Back to what kind of task you want to do - go back to my scenario about modeling automobiles. Replace any kind of modeling you can think of - and lay out the scenario. Then, start with the algorithm and work outwards. IOW, don't worry about displaying anything until the math works, and the steps result in the right numbers coming out. Then you can say "how can I see what's going on in the screen, instead of seeing System.out.prints?" Then you can say: "how can I change the parameters of the run, using the GUI?" - so that's how you can approach a task list for yourself.
When speaking of "IDE", why not use existing code, like Eclipse?
Answer: Amino (as a framework for a M&S application) serves many purposes: 1) it is a data model, not a view model or even command model. IDE's seem to be task-driven - Amino's future IDE will be data-driven in that it focuses on the content of the data, and different ways to interpret it. In this way it's more flexible than most folks' conception of the "traditional IDE." 2) Most IDE's are "heavy" - they have GUI widget objects that do very special things - Amino's IDE widgets will be "lightweight" in that they use Java swing components wrapped around data specifications - IOW a widget is made on the fly based on a data structure, not necessarily the plain instantiation of a specific widget. Of course this takes time to do (as far as the user's concerned) but the user probably won't realize just how long it takes compared to the normal way IDE's do it. 3) Amino's IDE will in fact be a data model, not a static application. If you're familiar with IBM's VisualAge SmallTalk, that's the kind of flexibility I'm looking for. Amino's main does not even presume a user interface - Views are not required. Amino is not your traditional application framework (of course I have a limited view of all the applications that are out there) 4) Amino is "targeted" towards Modeling and Simulation, however I've been careful to keep the core M&S-free. Amino can be used for any type of data and any type of domain application - spread-sheets, text editor, etc. However since those application types are done very nicely elsewhere, I'm not going to try to implement those. The point is to come up with free M&S software. 5) Eclipse looks large (~64M to download) - for now I'm trying to limit the amount of extra stuff people need to download - thus the utility of having different distribution modes. 6) Eclipse IS an application (and a GUI at that) - perhaps in the future I could have an "EclipseApplicationFrame" View, as a wrapper for the Eclipse GUI - that would be utilizing Amino to it's full potential for flexibility, if it's possible with Eclipse. However I suspect it would just be a matter of me "using" Eclipse classes, rather than actually running Eclipse as the main application.
Why are the screen shots so lame?
Answer: The focus of the project is M&S - data, not GUI beauty. As GUI functionality is added, the screen shots will indicate greater sopphistication. It takes work to make a GUI pretty - but more work to make it flexible.