Demo models‎ > ‎MacroABM‎ > ‎

The Bank class

1 Entities


The Bank class represents the single Bank involved in the MacroABM model.  Future extensions could easily incorporate more Bank objects to model a situation in which there is a financial sector comprised of several heterogeneous banks, in a similar way that there are several heterogeneous firms in the model already.

As discussed in The Class Hierarchy of 'Agents', the Bank class is derived from (i.e. is a subclass of) the Agent class.  The relationship with the Agent class can be seen at the start of the class declaration, where the keyword extends is used to show that the Bank class is derived from the Agent class:
 
@Entity
public class Bank extends Agent {
    […]
}
  
In the MacroABM model, just like the KFirm and CFirm, the Bank is an Entity class, as specified by the @Entity annotation.  This implies that the class is linked to a 'Bank' table in the database, and that all fields which are not annotated as @Transient are persisted in the database, when the simulation output is dumped to the output database.  Entity classes must specify a PanelEntityKey (annotated as @Id), which is a three-dimensional object which identifies the agent id, the simulation time and the simulation run. These three keys uniquely identify each record in the database:
  
@Id
private PanelEntityKey key;

 
The Object Relational Mapping (ORM) embedded in JAS-mine, which handles the representation of Java objects to the database, expects that the field names in the database are the same as the property names in the Java class.  Indeed, when exporting data to .csv files instead of the output database, the data is labelled using the name of the field as it appears in the code.

Class fields that are not simple types such as numerical values, strings or booleans cannot easily be represented in the output database.  Examples include Java objects such as the Bank class' CreditMap object, which is thus annotated @Transient, which indicates to JAS-mine to ignore this field when exporting data to the output database or .csv file.


2 The IDoubleSource interface

 
The Bank class implements the IDoubleSource interface.  This interface provides a simple way of asking a class to return a specific value.  In this case, it is used so that Bank data can be incorporated in the dynamic charts produced by the MacroObserver class.  (The MacroCollector also implements the IDoubleSource interface for the same reason - for use in passing data to the charts).  The interface requires to implement an Enum which lists all the variables that can be queried, and the getDoubleValue() method for returning their value (Box 1).

(In other JAS-mine projects, the IDoubleSource interface has been used by JAS-mine's Regression classes as a way of decoupling the regression model specification from the code: as long as a variable is enumerated in the specific Enum called Variables, it can be used (or removed) as a covariate in a regression model without the need to modify the code.  In the present MacroABM model, however, no such regressions are used).
 
 
 
public enum Variables {

        MonetaryBase,
        CreditSupply,
        LogCreditSupply,
        BadDebt,
        Debt;

}
    
@Override
public double getDoubleValue(Enum<?> variableDouble) {

        switch((Variables) variableDouble){
        
        case MonetaryBase:
            return monetaryBase;
            
        case CreditSupply:
            return creditSupply;
            
        case LogCreditSupply:
            if(creditSupply > 1)
                return Math.log(creditSupply);
            else
                return 0.;
            
        case BadDebt:
            return badDebt;
            
        case Debt:
            return debt;
            
        default:
            throw new IllegalArgumentException("Unsupported variable");
        
        }

}
Box 1. Implementation of the IDoubleSource interface in the Bank class.
 

3 The EventListener interface



Although not explicitly defined as implementing the EventListener interface, the Bank class inherits this property from its superclass Agent, whose class declaration begins in the following way:

public abstract class Agent implements EventListener

This means that the Bank object is able to be activated by the scheduler with the onEvent() method.  The calls that a Bank object is able to respond to, are enumerated in a specific Enum called Processes (see Box 1).

 
public enum Processes {

        Update,
        CreditAllocation,
        Accounting;

}

public void onEvent(Enum<?> type) {
        switch ((Processes) type) {
       
        case Update:
            update();
            break;
       
        case CreditAllocation:
            creditAllocation();
            break;
           
        case Accounting:
            accounting();
            break;

        }

}

Box 2. The Bank implements the EventListener interface.


These enum Processes are usually added to the schedule in the MacroModel class' buildSchedule() method, with lines such as:

modelEventGroup.addEvent(bank, Bank.Processes.Update);

modelEventGroup.addEvent(bank, Bank.Processes.CreditAllocation);

   
This means that the Process represented by the enums 'Update' and 'CreditAllocation' are added as Events to the EventGroup, which is scheduled to fire at each time-step.  The addEvent() method is used because the Update and CreditAllocation events are to be applied only to a single Bank object, which is the first argument of the method.  Compare this to the case when scheduling events for the set of KFirms or CFirms, where addCollectionEvent() method was used, so that the events would be applied to each KFirm or CFirm, respectively.

The significant methods of the Bank class, often ones that are called via the EventListener implementation, are discussed in the next section.

4 Methods

 
4.1 creditAllocation()

The bank compares the aggregate credit demand to its credit supply. If the aggregate credit demand is bigger,
the bank has to rank firms according to their net-worth-to-sale ratio. It then distributes the credit until it runs out of funds.

NOTE: there is a difference between the myopic version of the model, and the pseudo rational one:
1. Myopic: firms have access to a line of credit, and thus can decide how much to consume out of the loan that the bank offers them.
2. Pseudo-rational firms do not have access to a line of credit. Once the loan is granted, the firm uses it.


4.2 accounting()

The accounting method updates the Bank's accounts, including handling the bad debt with potential government bailouts.





Previous: The Consumption Good Firm class        Next: Data Output