Archive for the 'StrawberryFields' Category
Now Comes The Hard Part
As I have been discussing for some months now the target for the DOW has been 7500. This is a point that corresponds to intersection of the low that followed Sept 11 and tthe Iraq Invasion and a 25 year long term trend.
It is critical now is that this point holds. It is an extremely strong floor and if it breaks then that is a very bearish sign. Late Edit. It broke……..
It was tested back in November, but now it has fallen to this point in it’s own right. If it breaks then we are looking at the 5000′s. From the chart above you can see that the 200 month moving average has already been broken. Perhaps it would have been better if things had fallen more decisively earlier rather than dribbling down.
Good Luck.
February 19 2009 | Economics and StrawberryFields | No Comments »
Common Classes Done.
Things going well. The StrawberryFields common classes are complete apart from the 3D maths which takes a different sort of thinking. This includes the XSD data definition and all associated classes along with DOM or SAX parser code depending on whether the classes are to be streamed ie: they encapsulate HUGE data files, or manipulated ie: they encapsulate 3D entities. The command messaging interface that keeps track of manipulation of the tree allowing changes to the DOM tree to be undone; ie: 3D editing Undo/Redo complete. Memory leaks found and fixed. Code unit tested and working.
Am pretty happy with that.
Since the last update I have been playing with LOCMetics Lines of Code benchmarking tools so am able to state that since the 9th of Jan and 13th of Jan I have managed to write, test, debug and memory test an additional 7409 lines of code bringing this module up to 44622 lines of code.
The output this thing produces is here. Am also using SourceMonitor which provides more detail on code complexity. The idea being the more complex the more bugs.
So thats works out to be about 1852 lines of code per day (which includes comments btw). Interesting.
Pity I don’t get paid for this…..
Which reminds me I have to get a job. With the library as it is seems a good place to change focus. Unfortunately that means this will all grind back down to a crawl again.
January 13 2009 | StrawberryFields | No Comments »
Design Issue
Have you ever had one of those “Perhaps I could do it this way” after writing thousands of lines of code? In fact 37,213 so far in this library alone.
The option is between pure virtual functions, which are functions that don’t exist at the time you write the code, but which someone else can can implement later by deriving a class from your base. Versus using callbacks which are functions someone can write later and tell your code what they are, but which have nothing to do with classes.
The problem is that I am creating objects such as CSphere that contain the geometric data of an entity that will be drawn on the screen by the client, or processed by the backend to create a Finite Difference Time Domain grid. The code is also to be extensible which means that anyone may decide to use it to do anything and I have no way of knowing what they are going to do with the data. I just want them to be able to store and manipulate these objects and retrieve the data when needed.
The trick is that when they change something such as the size of an object, this may impact other objects, lets say the sphere now overlaps something else. Their code needs to be told to rebuild things.
How do we do that when we have no idea what their functions that have not even been thought of yet are called?
continue reading »
January 09 2009 | StrawberryFields | No Comments »
More Or Less On Track
Things have gone reasonably well this week on the StrawberryFields front.
The layer that will map the messages in the client to manipulation of the DOM tree is complete and unit tested.
Command undo redo is complete and unit tested
The major screw up this week, which may not end up being a screw up, was writing what I hoped would be a small stack and list template class rather than use STL. The problem was that by the the time I had handled the minimum functionality to ensure I don’t over run the end of the list, and a few other internal structures I found that CTinyStack and CTinyList were not so tiny after all….
continue reading »
January 09 2009 | StrawberryFields | No Comments »
Code Branching Policy.
While I am doing a brain dump of StrawberryField related things. It is worth mentioning the process I am using for code management.
StrawberryFields is currently hosted on SourceForge as the strawberryfield project, note the missing “s” with CVS here. At present I am mainly using SourceForge as a safe code repository. I will make a decison regarding bug tracking at a later date. It may be worth running my own version of BugZilla or similiar.
The rule that has been followed to date is that releases are branched from the main trunk and are not on it. For example when I decided to freeze the version 1.0 code I created a branch VERSION_1_BRANCH_2007_NOV_29 that will contain any future work to be done on version 1.0 if any.
The main trunk is now what will become version 2.0. The rule is fairly simple, the main trunk is the main development code. The branches are releases.
I don’t want to follow the reverse procedure of branching main versions from the trunk. It is probably a question of semantics if you think of the graph that results from branching code. In any case if you are looking for old releases, dump out a list of tags/branches/revisions and look for something of the form VERSION_X_X_X_BRANCH_YYY_MMM_DD Minor version numbers may not be included if not relevant.
January 06 2009 | StrawberryFields | No Comments »
Mid Development Class Structure
With the development of the StrawberryFields common classes getting to the point where I can see the end I thought it would be worth taking a cut of the documentation and testing the various tools I have for inserting and/or replacing licenses in the various source code directories, attaching the omnipresent GPL headers to all source files etc.
This went well methinks, the doxygen produced documentation for the StrawberryFields common libraries. It only took a couple of hours to run and load up to my web host, most of which was upload time and the perl scripts from StrawberryFields worked fine, thankfully. Have you ever tried cutting and pasting a new header into hundreds of source files simply to change the copyright date…
StrawberryFields Common Class Documentation
The main reason for this cut is to get a picture of what I need to do to close down the development of this block of code. The target for this chunk of work is to complete the collection of data storage and manipulation classes to the point that I can focus on the GUI and 3D graphics without have to also think XML internals at the same time.
I want to be able to “Create Sphere and Associate it with XYZ 3D Object Collection” , “Rotate Cylinder in the XY plane by such and such radians” or “Obtain the list of Points and Material types for all objects in the Tree” without having to dig into XML. To that extent I think I heve pretty well achieved it although I still have work to do on the SAX parser callbacks and the Object Rotation and Translation matrics.
Looking at the class structure from the graphical view of the class hierarchy and I think I think I have done reasonably well. It does not look too much like spaghetti.
The documentation here is the common classes that will form the base for the GUI client, the backend preprocessor that will take as input a DOM model of layers, various shapes, collections of various shapes etc and will output a smaller FDTD grid compatible array of material types that will be fed to a final processor. It also includes the parser for the time domain grid compatible file that will enable the processor to read the time domain grid.
This is only data storage and manipulation at this point. No graphics. No time domain algorithms. Nothing to actually produce the files.
It needs to be noted that I am between contracts here and living on savings. So when the post xmas job market opens up, this all get put on the back burner again. As such I can’t give a release date. But then version 1.0 took from 2003 until 2007 to be completed. Although most of that was working on the mathematical algorithms. The main system apart from the maths routines took about 6 months full time to write. The maths took several years.
As I now have working complex algorithms for both TLM and FDTD that use a general rational polynomial of any order as a material definition this should not take so long. Well at least I can cut out the algorithm development time.
Perhaps a year or so.
January 06 2009 | StrawberryFields | No Comments »
The Source Of Truth.
As described below StrawberryFields 2.0 is based around XML rather than the use of a MySQL database to store all the components of a model.
The reason why we need to use some way of relating components rather than write the whole thing into a grid and simply save that is that a model consists of objects such as circles and rectangles of material that need to be laid down in a certain order and we also want to be able to modify them later. If we wrote the objects to an array, there would be no way to go back and perhaps move an entity or change its material type.
The best analogy is bit mapped graphics versus vector graphics in 2D.
For StrawberryFields 1.0 MySQL was fine, except it required that any users also had this installed. I also found through usage that I tended to spend a lot of time digging through the database and making small modifications to the models. Cumbersome and certainly not something you would want to inflict on a user.
With this in mind the decision was made to use XML completely for all data storage. The attached xsd file defines the current data model that is being used for StrawberryFields. It includes the 3D model components and also such things as the settings of the client, server, backend processor, server status information. In fact everything is is now XML. Well except for error handling and **cough cough** the windows registry…..
The beauty of this is that if someone else wants to extend the system they can write for example a FDTD program that can use my front end to create and view a model and use the “Processor” file as input. Provided they conform to the interface spec, there is no reason it can not be integrated into StrawberryFields. In fact after all the modelling and preprocessing is done, the final step is simply execute a simple program that takes an xml file as input.
For those silly enough to actually want to see the data structure assuming that you have some form of XSD viewer or perhaps a great imagination.
StrawberryFields XML Schema Definition
January 06 2009 | StrawberryFields | No Comments »
A Total Rewrite?
As mentioned in the earlier post I learned a lot during my masters about what should be done rather than what I thought should be done. Key to amongst these is was the decision to move from using a database to store the objects being built and move to XML. Using that as a starting point a whole lot of changes have been made.
- Convert from SQL to XML for all data storage and manipulation
- Convert from building up models using a sequence of 2D material layers to direct 3D components such as Rods and Ellipses.
- Allow collections of objects to be grouped together and manipulated as single entities.
- Use the DOM tree as the single source of truth to define the relationships between components of the model and each other.
- Convert the backend to a lean and mean SAX based parser that takes as input the minimal set of data and has a low memory over head.
- Enable other people to produce backend applications that will easily integrate into the system. The idea being that provided they can read XML and produce output in the correct format all that old fortran code can be used.
- Enable other peoples modeling suites to be able to be used as input to my backend so that if someone already has something that can produce spheres, cones rods etc or FDTD grids then they could in theory feed that into my backend.
- Enable integration to things such as DDScat
So yes it looks to be a total rewrite.
continue reading »
January 05 2009 | StrawberryFields | No Comments »
A Bit Of History.
During the lead up to Y2K for those of you who remember that far back, there was a huge panic about the world coming to a stop as we potentially found ourselves back in 1900 again. There were massive tax incentives to fix the y2K problem and to top it off the web was just being rolled out.
What companies did was bring forward the next four or five years capital development cost and claimed anything that moved as Y2K compliance work. Need a new system? Mmmm will it be Y2K compliant? Cool lets do it now and claim the tax break.
Anyway what inevitably followed is that as Y2K came and as everyone had just updated all their systems there was no capital spend until everything that had been put in in 1999 was written down. End result no development, no new systems and we found ourselves in the Tech Wreck. Many of us simply had no work for a long time.
With nothing to do and it looked like a long time to do it, I took myself back off to uni to do a research masters in nano technology. Basically what I wanted to look at was momentum and energy transfer in the interaction between electromagnetism and arrays of nano sized objects. Being an IT type with a pure maths background I figured that modeling them would be a good idea and so StrawberryFields was born,
continue reading »
January 05 2009 | StrawberryFields | No Comments »
StrawberryFields Starts Again.
I have been trying to work out where to take this blog which has gone through various phases in the last couple of months depending on what I have been thinking about. Useful for me but probably not to anyone else.
As I am between contracts at the moment I have kicked off my 3D Nano Scale Modeling and Visualization suite StrawberryFields again and have decided to turn this blog into a development log. At least for now.
What it will aim to do is follow the development process through. As I collect interesting or useful information I will post it here along with updates of where the code is up to.
It may at times pick up various other topics if they occur to me. I have an interesting recipe I am working on for habenero chicken that is sure to leave everyone in tears, but I figure I had better try it myself first. Just can’t figure out what to coat it in. Herbs? Spices? Yoghurt?
January 05 2009 | StrawberryFields | No Comments »
