File: TODO

package info (click to toggle)
felt 3.02-4
  • links: PTS
  • area: main
  • in suites: slink
  • size: 16,460 kB
  • ctags: 6,885
  • sloc: ansic: 72,103; fortran: 3,614; yacc: 2,825; lex: 1,172; sh: 311; makefile: 279
file content (52 lines) | stat: -rw-r--r-- 3,098 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
Due to our own lack of experience/hardware/software, we definitely need
volunteers (we'd be willing to help where we could of course) for this stuff:

	o some sort of Windows interface - preferably velvet for Windows, but
          it could also be xfelt for Windows to start with (that would be 
          a lot easier).
        o as part of the above or as a separate undertaking, we need someone
          to compile the command line applications under DOS such that they
          will run on a 286 and while Windows is running.  The current binaries
          are built with DJGPP (gcc for DOS); the kind of binaries I'm talking
          about would need to be compiled with Microsoft or Borland C I think.
          If someone wanted to write pre- or post-processing applications for
          DOS that would be cool too.  Post-processing would be particularly
          easy if someone just wanted to parse out the standard felt ASCII
          output.  You could start with feltvu as a simple starting point.
          It might be nice if someone could port feltvu to a different 
          compiler as well.  I think most major DOS compilers probably
          handle graphics drivers in a more reliable way than the current
          set of DJGPP graphics lib drivers which people have had a lot of
          trouble with.
	o all of the above kinds of things (particularly just binaries of the
          command-line applications) for the Mac.

Things that maybe we'll get to someday, but if you want to try them first
then please feel free.  In no particular order:

	o make use of the Layout widget for geometry management of the main GUI
	o more intelligent use of the command line ... command completion
	  and argument specification ... type node hit space,
  	  get a "list of options" type delete hit space, get a prompt
	  for a number, type number hit return, etc.  In other
	  words make it something along the lines of some of the
	  popular CAD systems.
 	o improve plotting of displaced shapes. This probably means that
	  element writers need to provide a pointer to a function which
	  knows about the shape functions for an element and can fill in
	  a vector over the area or length of the element based on 
	  nodal displacements which, when plotted, will reflect the true
	  displaced shape of the element ...  
	o add snap to tool capability
	o robust quadrilateral mesh generation, 3-d mesh generation, etc, etc.
	o additional higher-order elements
	o fold Timoshenko beam theory into the standard beam, i.e., if
	  kappa or nu is given then expect a G and use Timoshenko
	  theory instead of Euler-Bernoulli.
	o put some real effort into internationalization.  The current 
	  functionality is there because it was easy.  More robust
	  implementation would mean maintaining a table, in code probably,
	  that mapped all possible input and as much output as possible
	  to a language determined by the user.
        o plug in something more universal than PPM to replace GIF - this will
          have to wait until some sort of agreeable format emerges of course.