You may have seen the articles Cathy Shive and I wrote on her blog about NSViewController and how to get it working well in your apps. Well now you can hear us talk about it! Scotty of the Mac Developer Network kindly had us both on for an episode of Late Night Cocoa, which you can download from iTunes here. It’ll be on the MacDevNet site too.

I talked about my preferences window system, I’ll have to wait a few weeks until I can put it up here with a sample app. Work will let up in August and I’ll have time to iron out a few bugs.

Thanks again to Scotty for having me on the episode, it was awesome!

I’m slowly getting everything ready to get espresso served here off the ground.  Part of that has been talking to a couple of graphic designers about site design and icon design.  After all, I’m a programmer and I can’t draw for the life of me.  Photoshop to me is an app that just puts loads of stuff all over my system.

Hopefully sometime in August things will start to take shape.

Apple introduced new scrollers in iTunes 7 and then moved on to give us the HUD, which many developers want their own scrollers for too. In Leopard, many of us thought that these would come in a nice, shiny box; but as they didn’t we’re all forced to roll our own. The common method is to draw all the components in Photoshop and then make a composite image when subclassing, but now with NSGradient and some nice additions to NSBezierPath all these have become quite easy to do, even for those with little artistic ability.

My first attempt was to do all of this using NSAffineTransforms, but without being able to mirror a bezier path, or define the the centre of rotation of a path or NSRect it becomes a loathsome task of tweaking and it just never quite works. So all the elements are drawn separately in this example, which is more code, but turned out to be far easier to code.

The important point to realise when subclassing NSScroller is that Apple’s documentation is out of date and some of the methods that we immediately assume we can subclass aren’t called. You can read the details in this thread on the cocoa-dev mailing list. You end up having to also implement -drawRect: and calling these documented (but unused) methods yourself.

The NSScroller consists first of the NSScrollerKnobSlot, the track on which the NSScrollerKnob itself lies. There are 2 (normally) buttons: in the vertical case the up arrow defined as the NSScrollerDecrementLine and the down arrow is the NSScrollerIncrementLine. I’ve implemented a method that checks to see which configuration the user has the scrollbars in, whether they are at the top and bottom or both together at the bottom. It does this by examining the AppleScrollBarVariant key in the global user defaults. If this (AFAICT undocumented) key changes then it calculated which configuration the user has selected. So when using these scrollers, the user can switch the configuration in System Preferences and the change can be seen. In the mode with both together at the bottom of the bar, there is also a top ‘socket’ that’s drawn.

The scrollbars also support horizontal scrolling, and I found that instantiating the vertical scroller without a frame works fine, but the only way to get a horizontal scroller is by using -initWithFrame:. I can only assume that apple are doing something under-the-hood for horizontal ones.

The final hiccup comes when you can to support the last 20% of users that use the scrollbar variant with both buttons at both ends. This is done in terminal and thankfully requires a restart of any program in which you want it to take effect. Problems come when trying to support this case when you want to know which button has been hit so you can draw it highlighted. The documented stuff from apple returns the same value whether the decrement line one end or the other is clicked! Making this impossible without tracking the mouse yourself, and I haven’t had the time to fix that. If I were using a program that didn’t respect my settings (I’m looking at you General Electric), then I’d get angry, so I included an NSScrollView subclass that checks for this case and just uses Apple’s scrollers if the user has selected it.

I think they’re pretty close to the iTunes ones, but mine are resoution-independent, but only Apple can give the perfect solution. You can download the XCode (3.1) project and sample app (10.5-only) here (alt link).

Hi all,

Just thought I’d let you know that you can now reach this website at www.espresso-served-here.com. I’m going to slowly be making changes to the site as I develop the brand for my software company. All previous links around the web to http://jonathandann.wordpress.com will still work though.

Jon

Having recently taken the plunge into Core Data I decided it was time to rip out all the model code from my current application and replace it with a Core Data version. After about a day I had my app up and running again but with one huge problem, the content of my NSOutlineView always appeared in a random order. Such is the problem with Core Data that NSManagedObjects store their to-many relationships in an NSSet, not an NSArray, which is unordered. So when your NSTreeController tries to display its data it appears in a random order.

This is not nice, imagine if the playlists in your iTunes library always changed their order? It gets even worse if your user wants to use drag and drop. In this case they decide the order, and they’d probably want it to stay that way.

The question of how to do this comes up so many times, along with the question of how to use multiple classes for nodes in the tree. Well, here’s your answer, and I’ve made a sample Xcode project to demonstrate. (alt link)

The Model

The model I’ve set up has a single abstract entity called TreeNode which has a boolean isLeaf attribute, an NSString *displayName, and an NSNumber *sortIndex (which is the one of the main reasons I’m writing this). It also has a to-many children relationship that has an inverse to-one parent relationship. Then there are two other entities: Group and Leaf both of which inherit from TreeNode. The Group entity has a few other boolean attributes that make writing an NSOutlineView delegate class really simple. The Leaf doesn’t have any of its own attributes yet, that’s for you guys to ponder.

The Tree Controller
The tree controller is our custom ESTreeController class. It is set up in the nib and has only 2 bindings, those of the @"managedObjectContext" and the @"sortDescriptors". It’s (obviously) operating in entity mode which is set to our abstract entity of TreeNode, and the children and leaf keypaths are set to attributes of the model: the oh-so-inventively named, children and isLeaf.

The Outline View
The outline view is also a subclass of NSOutlineView, but only to support expanded-state saving. The NSTableColumn in the view has only a single binding: the @"value" binding is bound to the tree controller’s @"arrangedObjects.displayName".

The rest of the UI only exists for demonstration purposes (so yeah its ugly), so we can see which ESTreeController method is invoked by the class’ standard actions.

The Sort Index
The @"sortIndex" attribute is the key to keeping the tree sorted, and it’s persistent allowing the sort to be maintained across sessions. It is simply an unsigned integer. Not having to apply a unique value to each node in the tree makes this a whole lot easier, nodes only require to have a unique number that defines their location within their own group. All we have to do is keep the sort index as the last index of the corresponding NSTreeNode’s index path.

There are 3 places this must be updated: on insertion, removal and movement. Functionality for this is provided by a single method -updateSortOrderOfModelObjects, which takes the last index of the tree node’s index path and sets it as the sort index of the representedObject. Simple. We make sure this is done correctly by overriding:

- (void)insertObject:(id)object atArrangedObjectIndexPath:(NSIndexPath *)indexPath;
- (void)insertObjects:(NSArray *)objects atArrangedObjectIndexPaths:(NSArray *)indexPaths;
- (void)removeObjectAtArrangedObjectIndexPath:(NSIndexPath *)indexPath;
- (void)removeObjectsAtArrangedObjectIndexPaths:(NSArray *)indexPaths;
- (void)moveNode:(NSTreeNode *)node toIndexPath:(NSIndexPath *)indexPath;
- (void)moveNodes:(NSArray *)nodes toIndexPath:(NSIndexPath *)startingIndexPath;

The tree controller is then bound to an NSSortDescriptor with keypath @"sortIndex".

Points To Note
NSTreeController’s -add:, -addChild:, -insert:, -insertChild: and remove: all call the plural forms of the above methods, and proceed to try and add a TreeNode entity to the tree. This can cause problems in the outline view’s delegate as this expects either Leaf or Group entities (try them in the sample project!), overriding these is usually necessary, which is what’s done with the -newLeaf: and -newGroup: actions.

The project also includes a bunch of categories that make life so much easier when working with NSIndexPath, NSTreeController and NSTreeNode.

Drag and Drop

-outlineView:writeItems: toPasteboard:
Write the index paths of the dragged items to the pasteboard as NSData objects.

-outlineView:validateDrop:proposedItem:proposedChildIndex:
Determine if the drop location is valid, not allowing drops on a leaf node (for the case of iTunes playlists being allowed to do this wouldn’t make sense), or if one of the dragged nodes is a group and the proposed location is on of its own descendants.

-outlineView:acceptDrop:item:childIndex:
Accept the drop and move the nodes for the dragged index paths. The edge case is is when dropping on the root of the tree. In this case the proposed parent of the drop location is nil and generating the index path for insertion therefore returns nil. We check for a nil parent and create a blank NSIndexPath if this is the case.

Summary
With the (relatively small) amount of code we have an NSOutlineView powered by Core Data and NSTreeController with some great features:
1) Drag and drop!
2) Persistent state saving!
3) Multiple entities in the tree (extend ad infinitum)
4) Sorting!
5) Some indispensable categories that make these classes so much easier to use (-treeNodeForObject: is great).

Download the Xcode project (requires Mac OS X 10.5)

Update
I’ve realised that there is some repeated code in the extensions, for my own work I’ve replaced the implementation of -flattenedContent with this:
- (NSArray *)flattenedContent;
{
return [[self flattenedNodes] valueForKey:@”representedObject”];
}

There are also these I’ve found useful:
- (void)setSelectedNode:(NSTreeNode *)node;
{
[self setSelectionIndexPath:[node indexPath]];
}

- (NSIndexPath *)indexPathToObject:(id)object;
{
return [[self treeNodeForObject:object] indexPath];
}


I recently did a post on NSViewController with Cathy Shive, and I realised today that the post was link to on the MacDevNet (Thanks Scotty!). I’m actually feeling like a developer for once.

Welcome all, nice to see you. Sit down, have a cup of coffee (espresso is served here), and I’ll write some more in a bit.

A common UI concept in Mac development is that of the source list, which everybody knows from iTunes, iPhoto, etc. To do this, NSTreeController can come in particular handy, although it can come with a bit of a headache as the API is somewhat lacking and a proper model is essential to making this easy to use.  I’m going to go over the solution that’s worked for me.

The starting point is the design of the model, we’ll begin by constructing a ‘node’ class that will represent a single item in our tree.  A node will need a few properties to work with the tree controller well.  The first is a ‘children’ property that’ll be an NSMutableArray intended to hold a series of our nodes.  The second is a BOOL, ‘isLeaf’ that we’ll toggle depending on whether we want the node to have the possibility of children or not.  Think of leaves as files and the opposite (I’ll call them groups) as folders, if you like.

Here’s how the code will look:

@interface ESNode : NSObject  {
 @protected
 ESNode *_parent;
 NSString *_nodeName;
 NSMutableArray *_children;
 BOOL _isLeaf;
}
@property(copy) NSString *nodeName;
@property(copy) NSMutableArray *children;
@property(assign) ESNode *parent;
@property(assign) BOOL isLeaf;

The problem is that objective-c 2.0 properties don’t have a mutableCopy keyword, so we’ll have to add the accessors ourselves, the isLeaf setter will do some magic too.

@synthesize nodeName = _nodeName;
@synthesize parent = _parent;
@dynamic isLeaf;
@dynamic children;

- (void)setIsLeaf:(BOOL)flag;
{
 _isLeaf = flag;
 if (_isLeaf)
 	self.children = [NSMutableArray arrayWithObject:self];
 else
 	self.children = [NSMutableArray array];
}
- (BOOL)isLeaf;
{
 return _isLeaf;
}

- (NSMutableArray *)children;
{
 return _children;
}

- (void)setChildren:(NSMutableArray *)newChildren;
{
 if (_children == newChildren)
 	return;
 [_children release];
 _children = [newChildren mutableCopy];
}

- (NSUInteger)countOfChildren;
{
 if (self.isLeaf)
 	return 0;
 return [self.children count];
}

- (void)insertObject:(id)object inChildrenAtIndex:(NSUInteger)index;
{
 if (self.isLeaf)
 	return;
 [self.children insertObject:object atIndex:index];
}

- (void)removeObjectFromChildrenAtIndex:(NSUInteger)index;
{
 if (self.isLeaf)
 	return;
 [self.children removeObjectAtIndex:index];
}

- (id)objectInChildrenAtIndex:(NSUInteger)index;
{
 if (self.isLeaf)
 	return nil;
 return [self.children objectAtIndex:index];
}

- (void)replaceObjectInChildrenAtIndex:(NSUInteger)index withObject:(id)object;
{
 if (self.isLeaf)
 	return;
 [self.children replaceObjectAtIndex:index withObject:object];
}

So we have a typical mutable array accessor and all the indexed accessors that allow you to place nodes anywhere in the children array. If you need to see more about why these are good to put in, then read the documentation on Key-Value Coding.  We’ve also included a ‘parent’ property that is non-retained so all nodes can know about their parent object and a ‘nodeName’ which I commonly use to identify my nodes in the tree.  The ‘isLeaf’ accessor will create either an empty mutable array ready for some children nodes or an array containing ’self’ if ’self’ has isLeaf set to YES.  The only caveat here is is you adopt the NSCopying or NSCoding protocols then you have to set isLeaf before setting the children array.

In the implementation of our ESNode class we’ll include a few useful methods for searching and filtering the tree:

- (NSArray *)descendants;
{
 NSMutableArray *descendantsArray = [NSMutableArray array];

for (ESNode *node in self.children) {
 	[descendantsArray addObject:node];
 	if (!node.isLeaf)
 		[descendantsArray addObjectsFromArray:[node descendants]];
 }

return [[descendantsArray copy] autorelease]; // return immutable
}

- (NSArray *)leafDescendants;
{
 NSMutableArray *leafsArray = [NSMutableArray array];

for (ESNode *node in self.children) {
 	if (node.isLeaf)
 		[leafsArray addObject:node];
 	else
 		[leafsArray addObjectsFromArray:[node leafDescendants]];
 }

return [[leafsArray copy] autorelease]; // return immutable
}

- (NSArray *)groupDescendants;
{
 NSMutableArray *groupsArray = [NSMutableArray array];

for (ESNode *node in self.children) {
 	if (!node.isLeaf) {
 		[groupsArray addObject:node];
 		[groupsArray addObject:[node groupDescendants]];
 	}
 }

return [[groupsArray copy] autorelease]; // return immutable
}

These allow us to get any of our node objects and construct an array of their descendants down to the bottom of the tree.  The final methods are our -init, -copyWithZone:, -initWithCoder: and -encodeWithCoder:

- (id)init;
{
 if (![super init])
 	return nil;
 self.nodeName = [NSString stringWithString:@"untitled"];
 self.isLeaf = NO; // this will also set the children array to [NSArray array].
 self.parent = nil;
 return self;
}

- (id)initGroup;
{
 return [self init];
}

- (id)initLeaf;
{
 if (![self init])
 	return nil;
 self.isLeaf = YES; // this will set the children array to an NSArray containing self.
 return self;
}

- (id)copyWithZone:(NSZone *)zone;
{
 ESNode *copy = [[[self class] allocWithZone:zone] init];
 if (!copy)
 	return nil;
 copy.nodeName = self.nodeName;
 copy.isLeaf = self.isLeaf;
 if (!self.isLeaf)
 	copy.children = self.children;
 return copy;
}

- (NSArray *)keysForEncoding;
{
 return [NSArray arrayWithObjects:@"isLeaf",@"children",@"parent",nil];
}

-(id)initWithCoder:(NSCoder *)coder;
{
 if (![self init])
 	return nil;

for (NSString *key in self.keysForEncoding) {
 	[self setValue:[coder decodeObjectForKey:key] forKey:key];
 }

return self;
}

- (void)encodeWithCoder:(NSCoder *)coder;
{
 for (NSString *key in self.keysForEncoding)
 	[coder encodeObject:[self valueForKey:key] forKey:key];
}

- (void)setNilValueForKey:(NSString *)key;
{
 if ([key isEqualToString:@"isLeaf"])
 	self.isLeaf = NO;
 else
 	[super setNilValueForKey:key];
}

The nice thing about doing your NSCoding in this way is that concrete subclasses of ESNode can simply implement a single method to adopt NSCoding:

- (NSArray *)keysForEncoding;
{
 return [[super keysForEncoding] arrayByAddingObjectsFromArray:[NSArray arrayWithObjects:@"key1",@"key2",@"key3",nil]];
}

Ok, so we have our node class and now we can use it with NSTreeController.  In your AppController class (this may be anything, for example an NSDocument subclass) create an NSMutableArray instance variable and call it treeContent. This array will hold instances of our ESNodes (or a subclass of ESNode if you want to extend it).

In the next part I’m assuming you’re used to Interface Builder and your app controller is either the File’s Owner of your nib, or is instantiated in the nib. Create an instance of NSTreeController in Interface Builder and bind the @”contentArray” to the keypath to the ‘treeContent’ array.  This tree controller will be powering an NSOutlineView.  Click through on your NSOutlineView instance until you can edit the bindings for the NSTableColumn and bind the @”value” of the table column in the outline view to the tree controller’s @”arrangedObjects” controller key with the keypath @”nodeName”. You’ll also have to set the tree controller’s children keypath to @”children” and the leaf keypath to @”isLeaf”.

In the -init method of the class that contains your treeContent array, create a bunch of ESNodes and fill the tree, set some children and whatnot and all of this will appear in your NSOutlineView when you run the program.

So once your tree is created, whether by you in the -init method or by your user at runtime, you’ll most likely want to search through the tree from time to time. In your app controller you can generate a ‘flat’ version of the tree with the following method:

- (NSArray *)discreteProjectContent;
{
 NSMutableArray *discreteProjectContent = [NSMutableArray array];
 for (ESSourceNode *item in self.projectContent) {
 	[discreteProjectContent addObject:item];
 	if (!item.isLeaf)
 		[discreteProjectContent addObjectsFromArray:[item descendants]];
 }
 return [[discreteProjectContent copy] autorelease]; // return immutable
}

Try it out. You get all the nodes in the tree in one long array, you can then search through the array for the item you want, for example by nodeName, and get a pointer to any item in the tree.

For really great additions to NSTreeController I point you in the direction of Wil Shipley’s blog, which has a great few NSTreeController extensions. When used in conjunction with the code above, you can get a pointer to an item in the tree and call his -indexPathToObject: method and you can then select any object in the tree.

Well if you’ve already read my post on installing MCNP on OS 10.4.10 then you mostly know what to do when installing on Leopard! Its nearly identical but with Apple migrating the X11 system they use to the one from X.org the X-window library that MCNP looks for is now a different name so the install fails and tells you it can’t find X11.

Some things are easier though, as X11 is installed by default you no longer have to install it from the Leopard DVD (unless you’ve selected not in install it in a custom installation of Leopard, in which case you probably know that you’ve done it).

Well when you’re at the stage that you’ve run the ./install linux mcnp command and have set the system option to Linux then you have to change the X11 path to the defaults except for the library name. This is now libx11la.lib then the rest f the install will run smoothly.

The new X11 in Leopard is buggy and the windows take an age to draw bit that’s going to be fixed soon. It all works fine its just the geometry plotting that is a bit slow, although this can be sped up if you switch to another app with a window that covers the X11 window during drawing (for example, iTunes), then switch back to find the window is completely drawn.

MCNP (Monte Carlo N-Particle) is a transport code that is used throughout the physics community to model how particles interact as they travel through a system. The code is quite old, and therefore requires tweaking to get it running on newer systems like Mac OS X 10.4.10. There are programs and compilers it needs to use when installing that aren’t included in Mac OS X anymore due to their age, and a few that are on the Mac OS X CD that came with your computer, but aren’t installed by default. The first things we need are:

A FORTRAN-77 compiler and a ‘C’ compiler of the same version.
The ‘fsplit’ program.
X11 installed.
The XCode tools.

The last is the easiest to install, and may come in useful if you ever do any programming under OS X. The XCode tools are on the Mac OS X install disc 1 that came with your Intel Mac. Open the CD and start the XCode installer (XCodeTools.mpkg) in

/Mac OS X Install Disc 1/XCode Tools/

During the installation, you get the option to customise the install, just select everything. I know some which are needed by MCNP, like the X11 SDK (software development kit), the GCC (GNU compiler collection) compilers the 10.4 SDK; but only selecting some messes things up and you never know when you’ll need them.

Once these are installed, you have to find the X11 installer (you’ve just installed the deveopment kit, but not the X11 application itself). X11 is the window server that allows you to display the geometry you define in MCNP. Double-click the X11User.pkg package on the Mac install CD at the path:

/Mac OS X Install Disc 1/System/Installation/Packages.

Run the installer and your done with the CD.

Now you need to install the FORTRAN-77 compiler, G77 version 3.4.0, and the C compiler CC 3.4.0. Both of these are done in the next step, are free, and are part of the GNU Comppiler Collection (GCC). This step is taken from

http://www1.gly.bris.ac.uk/~wookey/MEFTLG/g77.htm

Download the compilers’ source code to your desktop by clicking the link below, then double-click the downloded file to unpack the code to a folder on your desktop.

ftp.gnu.org/gnu/gcc/gcc-3.4.0/gcc-3.4.0.tar.gz

Then download the patch file to your desktop (which allows this old compiler set to run on an Intel Mac) by right clikcing this link and saving. This may add ‘.txt’ to the file, if it does, right click and select ‘Get Info’. Then remove the .txt suffix.

http://www1.gly.bris.ac.uk/~wookey/MEFTLG/gcc-3.4.0.diffs

Now you need to make your account an administrator account if it wasn’t one already, then open a Terminal window (found in /Applications/Utilities/) and type the following commands, hitting return at the end of each line:

cd Desktop
patch -p0 < ./gcc.3.4.0.diffs
cd gcc-3.4.0
./configure –enable-altivec –enable-languages=c,f77
sudo make bootstrap
sudo make install

(It seems that wordpress is removing two hyphens in an attempt to be smart. Both the ‘enable’ directives should be prepended by two hyphens, not a single one.  The single hyphen between ‘enable’ and ‘langauges’ should be single, though.)

The ’sudo make bootstrap’ command will ask for your password and take forever, even on my new 2.2GHz Core 2 Duo MacBook Pro! The ’sudo install’ command may tell you nothing else was required, so thats cool.This will create a few new programs in you /usr/local/bin folder, these are the compilers. One this is done you can delete the gcc-3.4.0 folder from your desktop. Then open up a terminal window, we are going to add the g77 (FORTRAN) and gcc-3.4.0 compilers to the standard folder where all things like this are kept. This allows you to invoke them from the terminal without typing the folder path each time too. We add them to this magical folder (/usr/bin) by creating a symbolic link (an alias in Mac language or shortcut if you speak Windows). In the terminal, type:

sudo ln -s /usr/local/bin/g77 /usr/bin/g77
sudo ln-s /usr/local/bin/gcc /usr/bin/gcc-3.4.0

Done! This leaves the 3.4.0 versions of the compilers in your /usr/local/bin folder so the XCode-installed new shiny versions don’t get messed with.Now we need to install ‘fsplit’ which is needed during the MCNP install when it splits up its monolithic FORTRAN source into smaller files, as I said MCNP is old. Download the fsplit source to your desktop:

http://ftp.bg.openbsd.org/OpenBSD/src/usr.bin/fsplit/fsplit.c

The open a Terminal and type

cd Desktop
cc -o fsplit fsplit.c

This compiles the program and places it on your desktop. Then type:

sudo mv ./fsplit /usr/bin

which moves the compiled program to the magical folder which the terminal likes all programs to be in. Then delete the fsplit.c file.

Now have a coffee, then we’re ready to install MCNP (finally). Put the CD in and open up a terminal window. When writing a folder path you can press tab, and the path will attempt to complete itself. If it can’t, for example when there are 2 folders beginning with the letter ‘c’, then press tab again and a list of all the possible matches will come up.

You’ll use this now if the MCNP CD isn’t called what I type below, mine was just called MCNP, but yours may not be. Whatever though, it will be the name that appears on the desktop.

mkdir /Applications/mcnp
cd /Applications/mcnp
gunzip -c /Volumes/MCNP/C701TAR.GZ | tar xvf -
gunzip -c /Volumes/MCNP/D200TAR.GZ | tar xvf -

This creates two folders in you /Applications/mcnp folder called ‘mcnp’ and ‘mcnp4c2′ the former containes cross-section data and the latter is the source code for MCNP itself. You have to place the cross sections is another folder, in terminal again:

cd /Applications/mcnp/mcnp/xs
sudo mkdir /usr/mcnpxs
mv ./* /usr/mcnpxs

Done. Now delete the /Applications/mcnp/mcnp folder. Leave the mcnp4c2 folder though, we need that now.

In Finder, go to the mcnp4c2 folder we just created and double click the install.fix file. This can be opened in TextEdit, where we just need to uncomment a few lines.Scroll down to the line that says FIXES FOR SYSTEM 5 (PC LINUX), below it is asks you to ‘uncomment the two lines for a debuggable version’ (some of you may need this when running MCNP), all this means is delete the ‘c’ charachter from the two lines below the statment, so they look like this:

5 2 4 1 1
DEBUG=”-g”

Save and close the file. Now you need to open up the mcsetup.id file in the mcnp4c2 folder. This opens in TextEdit again, so scroll down to the line that says ‘COM file to make MCNP 4C2 on the PC Linux’. The section of code below this line are all the commands used to compile MCNP, its automated later on, but these need to change a bit so they use the right compilers which we installed earlier. A few lines down you see

7 'mv compile mcnpc.c','cc -c mcnpc.c',......

Change the ‘cc’ part to read ‘gcc-3.4.0′ (without the quotation marks). A few lines down you see ‘./fsplit’ which you simply change to ‘fsplit’. This is ready to go now. You told it to use gcc-3.4.0, which is the same version as the g77 comiler we installed, this was very important.Open up a terminal window and type:

cd /Applications/mcnp/mcnp4c2
chmod a+x ./install
./install linux mncp

This then starts the install program, you’re greeted with a few options, you can change a few, but not all of them work with the Mac, and will tell you they haven’t been tested on linux (which were pretending to be, shhh don’t tell anyone).

In this mode you type 1.1, then press 5 to change to a linux setup, then type 2.3, press 2, then enter the amount of RAM you have according to the formula:

Where the value ‘RAM’ is in MB. This will say there’s an error with the value you typed (whoa THAT much RAM doesn’t exist!), again, MCNP = OLD. Just press C to continue.

Then back in the main MCNP install screen, press P to start installation. Should only take a few mins at most, not 20-40 like it says!

Once it’s done, you can delete most of the source. Open a terminal and type:

cd /Applications/mcnp
mv mcnp4c2/mcnp ./
mv mcnp4c2/xs ./
rm -r mcnp4c2
sudo ln -s /Applications/mcnp/mcnp /usr/bin/mcnp

Done! MCNP is now installed, and all you need to do is open a terminal and type ‘mcnp’ to run it! (It’ll ask for a input file, but if you’ve done all this then you’d probably know that!)

Ask questions, I’ll do my best!

The next few posts I think will be a little more obscure than the others.  As a scientist, I frequently have to work out how to install random science-y programs on my computer, and how to do the odd geeky thing.

 Occasionally I get asked how to do these things, and the things I need to do are frequently undocumented, or badly documented at best.  I hope someof you find these things useful.  If not, at least they’ll exist for when someone asks me how.