Amino FAQ

Anonymous CVS Issues
NoClassDefFoundError: Main
NoClassDefFoundError: WrongPolicy or IDLCompiler
Distributed Computing...
It Doesn't Seem To Do Anything...
How do I get started? I'm new to OpenSource/M&S...
Why not use existing Open Source IDE projects/code?
Why Are The Screen Shots So Lame?

Back To Top

Issues With CVS Access

Issue:
When I try to login anonymously to Amino CVS, I get booted-out:

	Parkers@parker1 ~
	$ cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/amino login
	Logging in to :pserver:anonymous@cvs.sf.net:2401/cvsroot/amino
	CVS password:
	cvs [login aborted]: end of file from server (consult above messages if any)

(this assumes you know to simply hit [enter] when prompted for a password)

	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:anonymous@cvs.sf.net:/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:anonymous@cvs.sf.net:/cvsroot/amino co Amino
	(and you'll need to repeat that for Simtein and tools modules.)

Back To Top

Issues With Build

Issue:
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)

Back To Top

Issue:
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)

Back To Top

Issue:
How can I avoid the complexity of being distributed?
or
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.

Back To Top

Issue:
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

Tips

Issues With Running

Issue:
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.

Back To Top

Project General

Issue:
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. 

Back To Top

Issue:
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.

Back To Top

Issue:
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.

Back To Top
SourceForge.net Logo